Re: WIP: Avoid creation of the free space map for small tables - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: WIP: Avoid creation of the free space map for small tables
Date
Msg-id CAA4eK1+n7hfwPpN7Rnx6-nHmtQykJMB-ViByxGsYh+VkqT0hcA@mail.gmail.com
Whole thread Raw
In response to Re: WIP: Avoid creation of the free space map for small tables  (John Naylor <john.naylor@2ndquadrant.com>)
Responses Re: WIP: Avoid creation of the free space map for small tables  (John Naylor <john.naylor@2ndquadrant.com>)
List pgsql-hackers
On Wed, Jan 9, 2019 at 9:00 PM John Naylor <john.naylor@2ndquadrant.com> wrote:
>
> On Wed, Jan 9, 2019 at 7:33 AM Mithun Cy <mithun.cy@enterprisedb.com> wrote:
> > 2. v11-Every-other-page and v11-last-page patches improve the
> > performance from base.
> > 3. IMHO v11-Every-other-page would be ideal to consider it improves
> > the performance and also to an extent avoid expansion if space is
> > already available.
>

Thanks, Mithun for performance testing, it really helps us to choose
the right strategy here.  Once John provides next version, it would be
good to see the results of regular pgbench (read-write) runs (say at
50 and 300 scale factor) and the results of large copy.  I don't think
there will be any problem, but we should just double check that.

> Good to hear. I'll clean up the every-other-page patch and include it
> in my next version.
>

+1.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query
Next
From: Amit Kapila
Date:
Subject: Re: Displaying and dumping of table access methods