Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Invent a "one-shot" variant of CachedPlans for better performanc
Date: 2013-01-05 19:15:30
Message-ID: 25197.1357413330@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On 4 January 2013 22:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Stephen FrostDate: 2013-01-05 19:31:53
Subject: Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
Previous:From: Phil SorberDate: 2013-01-05 18:34:02
Subject: Re: pg_retainxlog for inclusion in 9.3?

pgsql-committers by date

Next:From: Tom LaneDate: 2013-01-06 20:50:03
Subject: pgsql: Fix plpython build on older versions of OS X.
Previous:From: Magnus HaganderDate: 2013-01-05 15:58:02
Subject: pgsql: Add support for generating minimal recovery.conf when doingbase

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group