Re: why do we need two snapshots per query?

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: why do we need two snapshots per query?
Дата
Msg-id 4EBFBB0C0200002500042DD7@gw.wicourts.gov
обсуждение исходный текст
Ответ на why do we need two snapshots per query?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
> Tom Lane  wrote:
> Robert Haas  writes:
>> I can understand why you think it's a bad idea to preserve a
>> snapshot across multiple protocol messages (parse/bind/execute),
>> but why or how would it be a bad idea to keep the same snapshot
>> between planning and execution when the whole thing is being done
>> as a unit? You haven't offered any real justification for that
>> position,
>
> It's not hard to come by: execution should proceed with the latest
> available view of the database.
I don't think that stands as an intuitively obvious assertion.  I
think we need to see the argument which leads to that conclusion.
>> and it seems to me that if anything the semantics of such a thing
>> are far *less* intuitive than it would be to do the whole thing
>> under a single snapshot.
>
> In that case you must be of the opinion that extended query
> protocol is a bad idea and we should get rid of it, and the same
> for prepared plans of all types. What you're basically proposing is
> that simple query mode will act differently from other ways of
> submitting a query, and I don't think that's a good idea.
In what way would that difference be user-visible?
> One of the reasons I don't want to go this direction is that it
> would re-introduce causes of extended query protocol having poor
> performance relative to simple protocol. That's not something that
> users find intuitive or desirable, either.
If the simple protocol can perform better than the extended protocol,
it hardly seems like a good idea to intentionally cripple the fast
one to keep them at the same performance.  It seems like it would be
better to document the performance difference so that people can
weigh the trade-offs.
-Kevin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BuildFarm - Jaguar Check Failure
Следующее
От: Tom Lane
Дата:
Сообщение: Poor use of caching in rangetypes code