Re: Optimization for lazy_scan_heap

Поиск
Список
Период
Сортировка
От Rahila Syed
Тема Re: Optimization for lazy_scan_heap
Дата
Msg-id CAH2L28tesn0T_z6judNhLpCxgr1c7XbGutJctmNiVbqUY8Puqw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Optimization for lazy_scan_heap  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: Optimization for lazy_scan_heap  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
Hello,
 
Some initial comments on optimize_lazy_scan_heap_v2.patch.

>-               while (next_unskippable_block < nblocks)
>+               while (next_unskippable_block < nblocks &&
>+                      !FORCE_CHECK_PAGE(next_unskippable_block))

Dont  we need similar check of !FORCE_CHECK_PAGE(next_unskippable_block) in the below code
which appears on line no 556 of vacuumlazy.c ?

    next_unskippable_block = 0;
    if ((options & VACOPT_DISABLE_PAGE_SKIPPING) == 0)
    {
        while (next_unskippable_block < nblocks)


>           {
>                if ((vmstatus & VISIBILITYMAP_ALL_FROZEN) == 0)
>                    break;
>+               n_all_frozen++;
>            }
>            else
>            {
>                if ((vmstatus & VISIBILITYMAP_ALL_VISIBLE) == 0)
>                    break;
>+
>+               /* Count the number of all-frozen pages */
>+               if (vmstatus & VISIBILITYMAP_ALL_FROZEN)
>+                   n_all_frozen++;
>            }

I think its better to have just one place where we increment n_all_frozen before if-else block.

>            }
>            vacuum_delay_point();
>            next_unskippable_block++;
>+           n_skipped++;
>        }
>    }

Also, instead of incrementing n_skipped everytime, it can be set to 'next_unskippable_block' or 'next_unskippable_block -blkno'
once at the end of the loop.

Thank you,
Rahila Syed



On Thu, Aug 25, 2016 at 11:52 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: PATCH: two slab-like memory allocators
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: PATCH: two slab-like memory allocators