> Tom, Bruce, and others involved in this recurring TODO discussion... > > First, let me start by saying that I understand this has been discussed > many times before; however, I'd like to see what the current state of > affairs is regarding the possibility of using a unique index scan to > speed up the COUNT aggregate.
To sum up: 1. There are good technical reasons why not to do this. The pg aggregate system is very elegant...not worth compromising it for a specific case. 2. postgresql can do many things faster than oracle. If you prefer the way oracle behaves, use oracle. 3. workaround #1: just run analyze once in a while (you should do that anyways) and query pg_Class for the #tuples in a relation. 4. workaround #2: rig up a materialized view and query that. This will be faster than what oracle does, btw, at the price of some coherency. 5. understand that count(*) from t, although frequently used, is of dubious value in the general sense. Sooner or later someone will optimize this, but in light of the currently available workarounds it doesn't seem that important. 6. for large tables, you can get a pretty accurate count by doing: select count(*) * 10 from t where random() > .9; on my setup, this shaved about 15% off of the counting time...YMMV. Merlin ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
