Re: Optimization for lazy_scan_heap - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Optimization for lazy_scan_heap
Date
Msg-id CAD21AoCy8b7EAsy9Okj5LuS8mc+7MnrkUZM+5phoTeE3ZePn8Q@mail.gmail.com
Whole thread Raw
In response to Re: Optimization for lazy_scan_heap  (Anastasia Lubennikova <lubennikovaav@gmail.com>)
Responses Re: Optimization for lazy_scan_heap  (Rahila Syed <rahilasyed90@gmail.com>)
List pgsql-hackers
On Thu, Aug 25, 2016 at 1:41 AM, Anastasia Lubennikova
<lubennikovaav@gmail.com> wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world:  tested, passed
> Implements feature:       not tested
> Spec compliant:           not tested
> Documentation:            not tested
>
> Hi,
> I haven't tested the performance yet, but the patch itself looks pretty good
> and reasonable improvement.
> I have a question about removing the comment. It seems to be really tricky
> moment. How do we know that all-frozen block hasn't changed since the
> moment we checked it?

I think that we don't need to check whether all-frozen block hasn't
changed since we checked it.
Even if the all-frozen block has changed after we saw it as an
all-frozen page, we can update the relfrozenxid.
Because any new XIDs just added to that page are newer than the
GlobalXmin we computed.

Am I missing something?

In this patch, since we count the number of all-frozen page even
during not an aggresive scan, I thought that we don't need to check
whether these blocks were all-frozen pages.

> I'm going to test the performance this week.
> I wonder if you could send a test script or describe the steps to test it?

This optimization reduces the number of scanning visibility map when
table is almost visible or frozen..
So it would be effective for very large table (more than several
hundreds GB) which is almost all-visible or all-frozen pages.

For example,
1. Create very large table.
2. Execute VACUUM FREEZE to freeze all pages of table.
3. Measure the execution time of VACUUM FREEZE.
    I hope that the second VACUUM FREEZE become fast a little.

I modified the comment, and attached v2 patch.

Regards,

--
Masahiko Sawada

Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Collective typos in contrib/postgres_fdw (Was: Re: Incorrect comment in contrib/postgres_fdw/deparse.c)
Next
From: Amit Langote
Date:
Subject: Re: Declarative partitioning - another take