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: http://www.postgresql.org/mailpref/pgsql-hackers
