Re: why do we need two snapshots per query?
От | Florian Pflug |
---|---|
Тема | Re: why do we need two snapshots per query? |
Дата | |
Msg-id | AC7C8990-7C7C-42B3-B9D9-57C33EF64F03@phlo.org обсуждение исходный текст |
Ответ на | Re: why do we need two snapshots per query? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: why do we need two snapshots per query?
|
Список | pgsql-hackers |
On Nov11, 2011, at 17:06 , Tom Lane wrote: > Florian Pflug <fgp@phlo.org> writes: >> On Nov11, 2011, at 16:18 , Robert Haas wrote: >>> In the extend query protocol scenario, it seems to me that keeping the >>> snapshot would be both wrong and a bad idea. > >> Hm, but that'd penalize clients who use the extended query protocol, which >> they have to if they want to transmit out-of-line parameters. You could >> work around that by making the extended protocol scenario work like the >> simply protocol scenario if the unnamed statement and/or portal is used. > >> Since clients presumably use pipelined Parse,Bind,Execute messages when >> using the unnamed statement and portal, they're unlikely to observe the >> difference between a snapshot taken during Parse, Bind or Execute. > > I think it would be a seriously bad idea to allow the unnamed portal to > have semantic differences from other portals. We've gotten enough flak > about the fact that it had planner behavioral differences (enough so that > those differences are gone as of HEAD). Oh, I missed that and worked from the assumption that we're still special- casing the unnamed case. Since we don't, re-introducing a difference in behaviour is probably a bad idea. Still, optimizing only the simple protocol seems weird. best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: