Chris Browne <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Varun Mehta) writes: >> If I run an EXPLAIN on this query I can see that it is doing a >> sequential scan, which seems quite needless, as surely this >> information is cached in some secret location.
> [ example scenario snipped ] > If there were some "single secret place" with a count, how would you > suggest it address those 78 tuples and 16 transactions that aren't yet > (and maybe never will be) part of the count? It's worse than that: once some of those transactions have committed, the right answer is observer-dependent, since some onlooker transactions may see those guys as committed while others think they are not yet committed. So there could certainly not be just one secret place... There are solutions suggested in the archives, but they all amount to making COUNT(*)-with-no-WHERE-or-GROUP-BY-clause fast at the price of nontrivial distributed overhead for all updates --- overhead that would be paid whether or not the application ever did such a COUNT. That's not a tradeoff we've wanted to make in general. You can implement it yourself via triggers for specific tables that you think it's worth doing for. Also, if an approximate answer is good enough, there are a whole other set of possible solutions. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster