Re: more problems with count(*) on large table

With respect to the ALTER TABLE SET STATISTICS... how do I determine a
good value to use? This wasn't really clear in the pg docs. Also, do I
need to run ANALYZE on the table after I change the statistics?

Here are the EXPLAINs from the queries:

db=# explain select count(*) from prediction_accuracy where evtime
between '2007-09-25' and '2007-09-26';

QUERY PLAN

---------------------------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=475677.40..475677.41 rows=1 width=0)
-> Index Scan using pred_acc_evtime_index on prediction_accuracy
(cost=0.00..444451.44 rows=12490383 width=0)
Index Cond: ((evtime >= '2007-09-25 00:00:00-07'::timestamp
with time zone) AND (evtime <= '2007-09-26 00:00:00-07'::timestamp with
time zone))
(3 rows)

db=# explain select count(*) from prediction_accuracy where evtime
between '2007-09-26' and '2007-09-27';

QUERY PLAN

---------------------------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=486615.04..486615.05 rows=1 width=0)
-> Index Scan using pred_acc_evtime_index on prediction_accuracy
(cost=0.00..454671.07 rows=12777586 width=0)
Index Cond: ((evtime >= '2007-09-26 00:00:00-07'::timestamp
with time zone) AND (evtime <= '2007-09-27 00:00:00-07'::timestamp with
time zone))
(3 rows)

Mike

Gregory Stark wrote:
> "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?
>
>
>