vmehta@apple.com (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.
That would in fact surely *NOT* be the case.
If you have multiple users performing updates on that table
concurrently, with the possibility of some of those updates rolling
back, then it doesn't make sense for there to be any such "one place"
where a count would be stored.
Consider the case where you ask for COUNT(*) while the following set
of transactions are outstanding:
1. A transaction, which, as it turns out, will get rolled back, that has inserted 40 tuples;
2. A transaction which has modified 10 tuples, thereby generating 10 dead tuples and adding 10 new ones;
3. 14 transactions are outstanding, each of which have added 2 tuples to the table.
None of those transactions have COMMITted, so there are some 78 tuples
"in limbo" spread across 16 transactions.
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 is very possible that I am missing something, so I ask you: is
> there a faster way to find out how many rows are in a table? I've
> tried doing a COUNT(column) where I have an index on column, but it
> still does a sequential scan and it is still very very slow. What
> are my options?
Use of the index doesn't help because the index isn't forcibly up to
date. It has no notion of marking "index tuples" as dead/not visible.
Visibility information is only attached to the tuples themselves.
Look up "MVCC" for more details...
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/sap.html
Rules of the Evil Overlord #78. "I will not tell my Legions of Terror
"And he must be taken alive!" The command will be: ``And try to take
him alive if it is reasonably practical.''"
<http://www.eviloverlord.com/>
