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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: [COMMITTERS] pgsql: Invent a "one-shot" variant of CachedPlans for better performanc
Дата
Msg-id 25197.1357413330@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Invent a "one-shot" variant of CachedPlans for better performanc  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Re: [COMMITTERS] pgsql: Invent a "one-shot" variant of CachedPlans for better performanc  (Simon Riggs <simon@2ndQuadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Phil Sorber
Дата:
Сообщение: Re: pg_retainxlog for inclusion in 9.3?
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"