| From: | Harald Fuchs <nospam(at)sap(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: count(*) slow on large tables |
| Date: | 2003-10-06 15:08:36 |
| Message-ID: | pupthae74b.fsf@srv.protecting.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
In article <3F7D172E(dot)3060107(at)persistent(dot)co(dot)in>,
Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-10-06 16:05:29 | Re: more on initdb |
| Previous Message | Bruce Momjian | 2003-10-06 15:08:10 | pg_restore -d doesn't display output |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff | 2003-10-06 15:16:54 | Re: locking/performance, Solaris performance discovery |
| Previous Message | Tom Lane | 2003-10-06 14:30:14 | Re: locking/performance, Solaris performance discovery |