Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting

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

From: Mike Charnoky <noky(at)nextbus.com>
Date: Fri Sep 28 2007 - 16:23:11 EDT


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)

Do you need help?X

Mike

Gregory Stark wrote:
> "Alvaro Herrera" <alvherre@commandprompt.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?
>
>
>
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq Received on Fri Sep 28 16:27:38 2007

This archive was generated by hypermail 2.1.8 : Sun Oct 07 2007 - 11:57:49 EDT


Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library