From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: why do we need two snapshots per query? |
Date: | 2011-11-11 19:21:39 |
Message-ID: | m2zkg2ea7w.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-11-11 19:25:58 | Re: Re: pg_dump: schema with OID XXXXX does not exist - was Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers |
Previous Message | Alvaro Herrera | 2011-11-11 19:21:31 | Re: Re: pg_dump: schema with OID XXXXX does not exist - was Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers |