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

From: John Naylor <jcnaylor(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Avoid creation of the free space map for small tables
Date: 2018-12-01 07:12:11
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 11/29/18, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Nov 29, 2018 at 3:07 PM John Naylor <jcnaylor(at)gmail(dot)com> wrote:
>> Done. I tried adding it to several schedules, but for some reason
>> vacuuming an empty table failed to truncate the heap to 0 blocks.
>> Putting the test in its own group fixed the problem, but that doesn't
>> seem ideal.
> It might be because it fails the should_attempt_truncation() check.
> See below code:
> if (should_attempt_truncation(vacrelstats))
> lazy_truncate_heap(onerel, vacrelstats, vac_strategy);

I see. I think truncating the FSM is not essential to show either the
old or new behavior -- I could skip that portion to enable running the
test in a parallel group.

>> Can you please repeat the copy test you have done above with
>> fillfactor as 20 and 30?
> I will send the results in a separate email soon.

I ran the attached scripts which populates 100 tables with either 4 or
8 blocks. The test tables were pre-filled with one tuple and vacuumed
so that the FSMs were already created when testing the master branch.
The patch branch was compiled with a threshold of 8, but testing
inserts of 4 pages effectively simulates a threshold of 4. Config was
stock, except for fsync = off. I took the average of 40 runs (2
complete tests of 20 runs each) after removing the 10% highest and

# blocks master patch
4 19.1ms 17.5ms
8 33.4ms 30.9ms

# blocks master patch
4 20.1ms 19.7ms
8 34.7ms 34.9ms

It seems the patch might be a bit faster with fillfactor=20, but I'm
at a loss as to why that would be. Previous testing with a higher
threshold showed a significant performance penalty starting around 10
blocks [1], but that used truncation rather than deletion, and had a
fill-factor of 10.


-John Naylor

Attachment Content-Type Size
fsm-copy-setup.sql application/sql 854 bytes
fsm-copy-test-v3.sql application/sql 976 bytes

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-12-01 07:16:44 Re: pgsql: Switch pg_verify_checksums back to a blacklist
Previous Message Pavel Stehule 2018-12-01 06:32:41 Re: [HACKERS] proposal: schema variables