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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: John Naylor <jcnaylor(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Avoid creation of the free space map for small tables
Date: 2018-10-31 16:59:21
Message-ID: CA+Tgmob+QVEm4_RDiB6+-X1imHJGmt3Z1GdH2rkodwtzsBeLaw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 23, 2018 at 9:42 AM John Naylor <jcnaylor(at)gmail(dot)com> wrote:
> A case could be made for setting the threshold to 4, since not having
> 3 blocks of FSM in shared buffers exactly makes up for the 3 other
> blocks of heap that are checked when free space runs out.

That doesn't seem like an unreasonable argument. I'm not sure whether
the right threshold is 4 or something a little bigger, but I bet it's
not very large. It seems important to me that before anybody thinks
about committing this, we construct some kind of destruction case
where repeated scans of the whole table are triggered as frequently as
possible, and then run that test with varying thresholds. I might be
totally wrong, but I bet with a value as large as 32 you will be able
to find cases where it regresses in a big way.

We also need to think about what happens on the standby, where the FSM
is updated in a fairly different way.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-10-31 17:04:02 Re: pg_dumpall --exclude-database option
Previous Message Fabien COELHO 2018-10-31 16:44:26 Re: pg_dumpall --exclude-database option