|From:||John Naylor <jcnaylor(at)gmail(dot)com>|
|To:||Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>|
|Subject:||Re: WIP: Avoid creation of the free space map for small tables|
|Views:||Raw Message | Whole Thread | Download mbox|
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 , but that used truncation rather than deletion, and had a
fill-factor of 10.
|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|