Re: LP_DEAD hinting and not holding on to a buffer pin on leaf page(Was: [HACKERS] [WIP] Zipfian distribution in pgbench)

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: LP_DEAD hinting and not holding on to a buffer pin on leaf page(Was: [HACKERS] [WIP] Zipfian distribution in pgbench)
Дата
Msg-id 20170728024041.GB5417@marmot
обсуждение исходный текст
Ответ на Re: LP_DEAD hinting and not holding on to a buffer pin on leaf page(Was: [HACKERS] [WIP] Zipfian distribution in pgbench)  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
Peter Geoghegan <pg@bowt.ie> wrote:
>In Alik's workload, there are two queries: One UPDATE, one SELECT.  Even
>though the bloated index was a unique index, and so still gets
>_bt_check_unique() item killing, the regression is still going to block
>LP_DEAD cleanup by the SELECTs, which seems like it might be quite
>important there.  After all, _bt_check_unique() cleanup has to happen
>with an exclusive buffer lock held, whereas the kill_prior_tuple stuff
>happens with only a shared buffer lock held.  It's not hard to imaging
>that there will be a whole lot less LP_DEAD setting, overall.

Actually, there is a much bigger reason why SELECT statement LP_DEAD
killing matters more to Alik's workload than _bt_check_unique() LP_DEAD
killing: The UPDATE query itself does not affect indexed columns. Most
UPDATEs are actually HOT-safe (despite the degree of index bloat we
see), and so most UPDATEs will never reach _bt_check_unique().

-- 
Peter Geoghegan



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: LP_DEAD hinting and not holding on to a buffer pin on leaf page(Was: [HACKERS] [WIP] Zipfian distribution in pgbench)
Следующее
От: Tom Lane
Дата:
Сообщение: [HACKERS] PL_stashcache, or, what's our minimum Perl version?