Re: Optimization for lazy_scan_heap

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: Optimization for lazy_scan_heap
Дата
Msg-id CAD21AoAbiHuQJhXD2Vj1_hzzjVg5rGfiay_fNays5_RPBCo7MA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Optimization for lazy_scan_heap  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Optimization for lazy_scan_heap  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Sep 5, 2016 at 6:27 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 4 August 2016 at 05:57, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
>> While reviewing freeze map code, Andres pointed out[1] that
>> lazy_scan_heap could accesses visibility map twice and its logic is
>> seems a bit tricky.
>> As discussed before, it's not nice especially when large relation is
>> entirely frozen.
>>
>> I posted the patch for that before but since this is an optimization,
>> not bug fix, I'd like to propose it again.
>> Please give me feedback.
>>
>> [1] https://www.postgresql.org/message-id/20160505000840.epatoq6d2e556446%40alap3.anarazel.de
>
> If we have a freeze map now, surely tables will no longer be entirely frozen?

Well, if table is completely frozen, freezing for all pages will be skipped.

> What performance difference does this make, in a realistic use case?

I have yet to measure performance effect but it would be effect for
very large frozen table.

> How would we test this to check it is exactly correct?

One possible idea is that we emit the number of skipped page according
visibility map as a vacuum verbose message, and check it.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center



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

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: Vacuum: allow usage of more than 1GB of work mem
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Fun fact about autovacuum and orphan temp tables