| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Kevin Grittner <kgrittn(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Alik Khilazhev <a(dot)khilazhev(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: LP_DEAD hinting and not holding on to a buffer pin on leaf page (Was: [WIP] Zipfian distribution in pgbench) |
| Date: | 2017-07-28 02:40:41 |
| Message-ID: | 20170728024041.GB5417@marmot |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-07-28 02:48:35 | PL_stashcache, or, what's our minimum Perl version? |
| Previous Message | Peter Geoghegan | 2017-07-28 02:05:33 | Re: LP_DEAD hinting and not holding on to a buffer pin on leaf page (Was: [WIP] Zipfian distribution in pgbench) |