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

From Tom Lane
Subject Re: Help with count(*)
Date
Msg-id 26338.1068996163@sss.pgh.pa.us
Whole thread Raw
In response to Re: Help with count(*)  (Neil Conway <neilc@samurai.com>)
List pgsql-performance
Neil Conway <neilc@samurai.com> writes:
> Tom Lane <tgl@sss.pgh.pa.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.

That's defensible when the user issued the BEGIN himself.  When the
BEGIN is coming from some interface library's autocommit logic, it's
a lot less defensible.  If you consult the archives, you will find
actual user complaints about "why is now() returning a very old time?"
that we traced to use of interface layers that handle "commit()" by
issuing "COMMIT; BEGIN;".

When BEGIN actually is issued by live application logic, I'd expect it
to be followed immediately by some kind of command --- so the user would
be unable to tell the difference in practice.

Hannu moved this thread to -hackers, please follow up there if you want
to discuss it more.

            regards, tom lane

pgsql-performance by date:

Previous
From: "Nick Fankhauser"
Date:
Subject: Re: n_distinct way off, but following a pattern.
Next
From: Andrew Sullivan
Date:
Subject: Re: INSERT extremely slow with large data sets (fwd)