Horton

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

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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:39:19Z
Lists: pgsql-hackers 
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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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.