Re: WIP: Avoid creation of the free space map for small tables

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>
Cc: Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Avoid creation of the free space map for small tables
Date: 2019-01-10 03:50:37
Message-ID: CAA4eK1+n7hfwPpN7Rnx6-nHmtQykJMB-ViByxGsYh+VkqT0hcA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 9, 2019 at 9:00 PM John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> wrote:
>
> On Wed, Jan 9, 2019 at 7:33 AM Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-01-10 03:58:07 Re: Displaying and dumping of table access methods
Previous Message Amit Kapila 2019-01-10 03:32:22 Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query