Re: start of transaction (was: Re: [PERFORM] Help with count(*))
От
Neil Conway
Тема
Re: start of transaction (was: Re: [PERFORM] Help with count(*))
Дата
Msg-id
873ccnc49e.fsf@mailbox.samurai.com
Ответ на
start of transaction (was: Re: [PERFORM] Help with count(*)) (Hannu Krosing)
Список
Дерево обсуждения
start of transaction (was: Re: [PERFORM] Help with count(*)) Hannu Krosing <hannu@tm.ee>
Re: start of transaction (was: Re: [PERFORM] Help with count(*)) Tom Lane <tgl@sss.pgh.pa.us>
Re: start of transaction (was: Re: [PERFORM] Help with Dennis Bjorklund <db@zigo.dhs.org>
Re: start of transaction (was: Re: [PERFORM] Help with count(*)) Neil Conway <neilc@samurai.com>
Re: start of transaction (was: Re: [PERFORM] Help with count(*)) Greg Stark <gsstark@mit.edu>
Re: start of transaction (was: Re: [PERFORM] Help with Stephan Szabo <sszabo@megazone.bigpanda.com>
Hannu Krosing writes: > For me, the "start of transaction" is not about time, but about grouping > a set of statements into one. So making the exact moment of "start" be > the first statement that actually does something with data seems > perfectly reasonable. This might be a perfectly logical change in semantics, but what benefit does it provide over the old way of doing things? What does BEGIN actually do now, from a user's perspective? At present, it "starts a transaction block", which is pretty simple. If we adopted the proposed change, it would "change the state of the system so that the next command is part of a new transaction". This is naturally more complex; but more importantly, what benefit does it ACTUALLY provide to the user? (I can't see one, but perhaps I'm missing something...) > Delaying the locking effects of transactions as long as possible can > increase performance overall, not just for pathological clients that sit > on idle open transactions. I agree, but this is irrelevant to the semantics of now(). -Neil
В списке pgsql-hackers по дате отправления
От: Neil Conway
Дата: