| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> |
| Cc: | "A(dot) Kretschmer" <andreas(dot)kretschmer(at)schollglas(dot)com>, <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: more problems with count(*) on large table |
| Date: | 2007-09-28 18:01:47 |
| Message-ID: | 871wciwtx0.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"Alvaro Herrera" <alvherre(at)commandprompt(dot)com> writes:
> A. Kretschmer wrote:
>> am Fri, dem 28.09.2007, um 11:56:46 -0400 mailte Mike Charnoky folgendes:
>> > Hi,
>> >
>> > I am still having problems performing a count(*) on a large table. This
>> >
>> > Now, certain count(*) queries are failing to complete for certain time
>> > ranges (I killed the query after about 24 hours). The table is indexed
>> > on a timestamp field. Here is one query that hangs:
>>
>> Again: an index can't help! Because of MVCC: 'select count(*)' without
>> WHERE-condition forces an seq. table-scan.
>
> But he does have a WHERE condition. THe problem is, probably, that the
> condition is not selective enough so the planner chooses to do a
> seqscan.
What does EXPLAIN SELECT ... say?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2007-09-28 18:04:25 | Re: row->ARRAY or row->table casting? |
| Previous Message | A. Kretschmer | 2007-09-28 17:54:42 | Re: more problems with count(*) on large table |