On Fri, Nov 11, 2011 at 2:21 PM, Dimitri Fontaine
<dimi...@2ndquadrant.fr> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> Considering that GetSnapshotData() is the number-one consumer of CPU
>> time on many profiling runs I've done, this seems needlessly
>> inefficient.  Can't we arrange to retain the snapshot used for parse
>> analysis / planning and reuse it for the portal that we create just
>> afterwards?  Off the top of my head, I'm not exactly sure how to do
>> that cleanly, but it seems like it should work.
> Please refer to this thread:
>  http://postgresql.1045698.n5.nabble.com/One-Shot-Plans-td4488820.html
> It seems one of the more prominent drawback of Simon's approach to
> one-shot plans then was which snapshot it's running against, so your
> proposal to optimize one-shot plan by enforcing the use of a single
> snapshot looks like a step forward here.
> The other problem is how to recognize a query as being a candidate for
> one-shot optimization, but I guess exec_simple_query (as opposed to the
> v3 protocol) applies.

It would be nice if we could kill two birds with one stone, but I'm
not sure it we'll be that lucky.  The trouble is that PortalStart()
does different things depending on what opinion ChoosePortalStrategy()
offers about the statement to be processed, and the code that sets the
snapshot for parsing and planning uses a completely separate (and
generally simpler) heuristic.  Maybe there's an easy way to centralize
that decision-making; I'll have a look.  If not, I'll settle for
improving the case that looks improvable.

In terms of improving things for the extended protocol, I think there
may be other ways to do that, but this particular optimization won't
apply, so it's a separate project...

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to