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

From John Naylor
Subject Re: WIP: Avoid creation of the free space map for small tables
Date
Msg-id CAJVSVGVDGccZy61TStidtYV67gW2qbbUyoaZ7jqo-v4s8rA6Mw@mail.gmail.com
Whole thread Raw
In response to Re: WIP: Avoid creation of the free space map for small tables  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: WIP: Avoid creation of the free space map for small tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 10/6/18, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
> On Sat, Oct 6, 2018 at 7:47 AM John Naylor <jcnaylor@gmail.com> wrote:
>> A while back, Robert Haas noticed that the space taken up by very
>> small tables is dominated by the FSM [1]. Tom suggested that we could
>> prevent creation of the FSM until the heap has reached a certain
>> threshold size [2]. Attached is a WIP patch to implement that. I've
>> also attached a SQL script to demonstrate the change in behavior for
>> various scenarios.
>
> Hi John,
>
> You'll need to tweak the test in contrib/pageinspect/sql/page.sql,
> because it's currently asserting that there is an FSM on a small table
> so make check-world fails.

Whoops, sorry about that; the attached patch passes make check-world.
While looking into that, I also found a regression: If the cached
target block is the last block in the relation and there is no free
space, that block will be tried twice. That's been fixed as well.

Thanks,
-John Naylor

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_upgrade failed with ERROR: null relpartbound for relation18159 error.
Next
From: Tom Lane
Date:
Subject: Re: Defaulting to password_encryption = scram-sha-256