Re: count(*) slow on large tables
От | Harald Fuchs |
---|---|
Тема | Re: count(*) slow on large tables |
Дата | |
Msg-id | pupthae74b.fsf@srv.protecting.net обсуждение исходный текст |
Ответ на | count(*) slow on large tables (Dror Matalon <dror@zapatec.com>) |
Список | 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.
В списке pgsql-performance по дате отправления: