start of transaction (was: Re: [PERFORM] Help with count(*))

Redirected to -hackers

Neil Conway kirjutas L, 15.11.2003 kell 22:20:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > (I believe the previous discussion also agreed that we wanted to
> > postpone the freezing of now(), which currently also happens at
> > BEGIN rather than the first command after BEGIN.)
>
> That doesn't make sense to me: from a user's perspective, the "start
> of the transaction" is when the BEGIN is issued, regardless of any
> tricks we may play in the backend.

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. If you really need to preserve time, do "select
current_timestamp" and use the result.

> Making now() return the time the current transaction started is
> reasonably logical; making now() return "the time when the first
> command after the BEGIN in the current transaction was issued" makes a
> lot less sense to me.

for me "the time the current transactuion is started" == "the time when
the first command after the BEGIN in the current transaction was issued"
and thus I see no conflict here ;)

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.

Probably the latest time we can start the transaction is ath the start
of executor step after the first statement in a transaction is planned
and optimized.

---------------
Hannu