Re: Turning off HOT/Cleanup sometimes

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: 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-12 14:20:27
Message-ID: 20140912142026.GL4701@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> On 12 September 2014 14:54, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>
> > My idea is that we would have a new executor flag, say
> > EXEC_FLAG_READ_ONLY; we would set it on nodes that are known to be
> > read-only, and reset it on those that aren't, such as LockRows and
> > ModifyTable (obviously we need to pass it down correctly from parent to
> > children). Then in ExecInitSeqScan and ExecInitIndexScan, if we see the
> > flag set, we call heap/index_set_allow_prune(false) for the heap scan;
> > same thing in index scans. (I envisioned it as a boolean rather than
> > enabling a certain number of cleanups per scan.)
> >
> > I tried to code this but I think it doesn't work correctly, and no time
> > for debug currently. Anyway let me know what you think of this general
> > idea.
>
> Thanks for looking at this.
>
> My concern was to ensure that UPDATEs and DELETEs continue to call
> heap_page_prune_opt while larger SELECTs do not.
>
> This is achieved without a counter, so after some thought like it
> better; simple is good. Happy to progress from here, or you can?

Please feel free to take over.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-09-12 14:20:53 Re: implement subject alternative names support for SSL connections
Previous Message Simon Riggs 2014-09-12 14:10:08 Re: Turning off HOT/Cleanup sometimes