Re: start of transaction (was: Re: [PERFORM] Help with count(*)) - Mailing list pgsql-hackers

From Neil Conway
Subject Re: start of transaction (was: Re: [PERFORM] Help with count(*))
Date
Msg-id 873ccnc49e.fsf@mailbox.samurai.com
Whole thread Raw
In response to start of transaction (was: Re: [PERFORM] Help with count(*))  (Hannu Krosing <hannu@tm.ee>)
Responses Re: start of transaction (was: Re: [PERFORM] Help with count(*))  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Hannu Krosing <hannu@tm.ee> 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 by date:

Previous
From: bpalmer
Date:
Subject: Re: We're finally there ...
Next
From: Neil Conway
Date:
Subject: start of transaction (was: Re: [PERFORM] Help with count(*))