Re: Turning off HOT/Cleanup sometimes

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Turning off HOT/Cleanup sometimes
Date: 2014-09-14 20:37:45
Message-ID: CA+U5nM+WxVDC9tG5eU858LL59XaOWUQoMRzJZ2JFRS_dseMf_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12 September 2014 18:19, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 12 September 2014 15:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>> After a little bit I remembered there was already a function for this.
>> So specifically, I'd suggest using ExecRelationIsTargetRelation()
>> to decide whether to mark the scan as requiring pruning.
>
> Sounds cool. Thanks both, this is sounding like a viable route now.

Yes, this is viable.

Patch attached, using Alvaro's idea of use-case specific pruning and
Tom's idea of aiming at target relations. Patch uses or extends
existing infrastructure, so its shorter than it might have been, yet
with all that bufmgr yuck removed.

This is very, very good because while going through this I notice the
dozen or more places where we were pruning blocks in annoying places I
didn't even know about such as about 4-5 constraint checks. In more
than a few DDL commands like ALTER TABLE and CLUSTER we were even
pruning the old relation prior to rewrite.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
hot_disable.v5.patch application/octet-stream 14.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2014-09-14 22:30:27 Re: SKIP LOCKED DATA (work in progress)
Previous Message Peter Geoghegan 2014-09-14 20:34:30 Re: B-Tree support function number 3 (strxfrm() optimization)