Re: Help with count(*) - Mailing list pgsql-performance

From Tom Lane
Subject Re: Help with count(*)
Date
Msg-id 4987.1068842326@sss.pgh.pa.us
Whole thread Raw
In response to Re: Help with count(*)  (Will LaShell <will@lashell.net>)
Responses Re: Help with count(*)
Re: Help with count(*)
List pgsql-performance
Will LaShell <will@lashell.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

pgsql-performance by date:

Previous
From: Christopher Browne
Date:
Subject: Re: Help with count(*)
Next
From: Tom Lane
Date:
Subject: Re: constant vs function param differs in performance