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
|
Список | 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 по дате отправления: