Re: count(*) slow on large tables
Harald Fuchs <nospam@sap.com>
From: Harald Fuchs <nospam@sap.com>
To: pgsql-performance@postgresql.org
Date: 2003-10-06T15:08:36Z
Lists: pgsql-hackers, pgsql-performance
In article <3F7D172E.3060107@persistent.co.in>, Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes: > Dror Matalon wrote: >> I smell a religious war in the aii:-). Can you go several days in a >> row without doing select count(*) on any >> of your tables? I suspect that this is somewhat a domain specific >> issue. In some areas >> you don't need to know the total number of rows in your tables, in >> others you do. > If I were you, I would have an autovacuum daemon running and rather > than doing select count(*), I would look at stats generated by > vacuums. They give approximate number of tuples and it should be good > enough it is accurate within a percent. The stats might indeed be a good estimate presumed there were not many changes since the last VACUUM. But how about a variant of COUNT(*) using an index? It would not be quite exact since it might contain tuples not visible in the current transaction, but it might be a much better estimate than the stats.