Not to mention it only increases the speed of:
SELECT count(*) FROM foo;
and not:
SELECT count(*) FROM foo WHERE bar;
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Dann Corbit" <DCorbit@connx.com>
Cc: "Doug McNaught" <doug@wireboard.com>;
<pgsql-hackers@postgresql.org>
Sent: Friday, April 05, 2002 3:21 PM
Subject: Re: [HACKERS] Suggestion for optimization
> "Dann Corbit" <DCorbit@connx.com> writes:
> > At any rate, there is clearly a concept of cardinality in any
case.
>
> Certainly. The count(*) value is perfectly well defined within any
one
> transaction. We *could*, if we wanted to, implement bookkeeping
logic
> that would keep track of the number of rows inserted by all
transactions
> and allow derivation of the count-as-seen-by-any-one-transaction at
all
> times. The point is that that logic would be vastly more complex
than
> you thought it would be; and it would not be optional. (AFAICS, the
> counts would have to be determined at postmaster startup and then
> maintained faithfully by all transactions. There wouldn't be any
good
> way for a transaction to initialize the bookkeeping logic
on-the-fly ---
> unless you call acquiring an exclusive lock on a table good.) No
one
> who's looked at it has thought that it would be a good tradeoff for
> making count(*) faster.
>
> regards, tom lane
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>