From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Will LaShell <will(at)lashell(dot)net> |
Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, Christopher Browne <cbbrowne(at)acm(dot)org>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Help with count(*) |
Date: | 2003-11-14 20:38:46 |
Message-ID: | 4987.1068842326@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
Will LaShell <will(at)lashell(dot)net> writes:
> Hannu Krosing wrote:
>> Can't the backend be made to delay the "real" start of transaction until
>> the first query gets executed ?
> That seems counter intuitive doesn't it? Why write more code in the
> server when the client is the thing that has the problem?
Because there are a lot of clients with the same problem :-(
A more principled argument is that we already postpone the setting of
the transaction snapshot until the first query arrives within the
transaction. In a very real sense, the setting of the snapshot *is*
the start of the transaction. So it would make sense if incidental
stuff like VACUUM also thought that the transaction hadn't started
until the first query arrives. (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.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-11-14 20:42:49 | Re: [CORE] 7.4RC2 regression failur and not running stats collector process |
Previous Message | Christopher Browne | 2003-11-14 19:51:48 | Re: [CORE] 7.4RC2 regression failur and not running stats collector process |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-11-14 20:59:14 | Re: constant vs function param differs in performance |
Previous Message | Will LaShell | 2003-11-14 19:40:23 | Re: Help with count(*) |