Re: Help with count(*)

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-performance by date

  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(*)