From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Dann Corbit" <DCorbit(at)connx(dot)com> |
Cc: | "Doug McNaught" <doug(at)wireboard(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Suggestion for optimization |
Date: | 2002-04-05 20:21:47 |
Message-ID: | 9823.1018038107@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Dann Corbit" <DCorbit(at)connx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2002-04-05 20:35:19 | Re: Suggestion for optimization |
Previous Message | Dann Corbit | 2002-04-05 20:08:11 | Re: Suggestion for optimization |