Horton

Re: PoC plpgsql - possibility to force custom or generic plan

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, Petr Jelinek <petr.jelinek@2ndquadrant.com>, David Steele <david@pgmasters.net>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Jim Nasby <Jim.Nasby@bluetreble.com>
Date: 2017-09-11T12:44:44Z
Lists: pgsql-hackers 
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 9/8/17 13:14, Simon Riggs wrote:
>> 2. Allow a SET to apply only for a single statement
>> SET guc1 = x, guc2 = y FOR stmt
>> e.g. SET max_parallel_workers = 4 FOR SELECT count(*) FROM bigtable
>> Internally a GUC setting already exists for a single use, via
>> GUC_ACTION_SAVE, so we just need to invoke it.

> This doesn't read well to me.  It indicates to me "make this setting for
> this query [in case I run it later]", but it does not indicate that the
> query will be run.

Robert's original LET ... IN ... syntax proposal might be better from that
standpoint.

			regards, tom lane

Commits

  1. Add plan_cache_mode setting

  2. Add some noreturn attributes to help static analyzers

  3. document when PREPARE uses generic plans

  4. Redesign the plancache mechanism for more flexibility and efficiency.