Re: Re: [COMMITTERS] pgsql: Invent a "one-shot" variant of CachedPlans for better performanc - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Invent a "one-shot" variant of CachedPlans for better performanc
Date
Msg-id 25197.1357413330@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Invent a "one-shot" variant of CachedPlans for better performanc  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Re: [COMMITTERS] pgsql: Invent a "one-shot" variant of CachedPlans for better performanc
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> On 4 January 2013 22:42, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Invent a "one-shot" variant of CachedPlans for better performance.

> Just a moment of reflection here but I did already invent a "one-shot"
> plan concept in a patch submission to 9.2, called exactly that, which
> enables a variety of optimizations, this being one.

If you're speaking of
http://archives.postgresql.org/pgsql-hackers/2011-06/msg01168.php

that patch was vastly more invasive than this one, with vastly less
clear performance characteristics (none of which were documented by test
cases).  And it had the potential for unexpected user-visible semantics
changes; for instance, as submitted it made EXPLAIN produce results
different from what might actually happen at execution.  I don't think
there's any comparison to this patch at all except in the nomenclature.

> We need a full "one-shot" concept linking the planner and executor for
> all sorts of reasons, not just this one. We can discuss the
> practicality of individual optimizations but the linkage should be
> clear throughout the whole infrastructure.

I thought then, and I think now, that such a concept was too squishy
to be useful as an actual guide to what to change.  The particular
arguments you advanced then have been overtaken by events anyway;
notably that Marti Raudsepp's work on caching stable subexpressions at
execution seems like a much more general answer to the problem of
handling stable functions efficiently.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Phil Sorber
Date:
Subject: Re: pg_retainxlog for inclusion in 9.3?
Next
From: Stephen Frost
Date:
Subject: Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"