, May 30, 2011 8:35:39 PM
Subject: RES: [GENERAL] SELECT COUNT(*) execution time on large tables
(v9.0.4-1)
David, Thanks for your reply.
I will probably use the strategy of a trigger driven counter, with temporal
strategy devising current month totals and up to last month total as current
month
ssunto: RE: [GENERAL] SELECT COUNT(*) execution time on large tables
(v9.0.4-1)
Counting live data is inherently imprecise. There are supposedly some
system tables that can give you rough numbers.
You would be better off figuring out an alternative method to get the data
you desire and stop c
On 05/27/2011 12:41 PM, Carlos Sotto Maior (SIM) wrote:
I have browsed catalog tables, digging for a real time Row.count but so far
did not find any.
See http://wiki.postgresql.org/wiki/Slow_Counting which shows you where
the one system count estimate is at, as well as suggesting links to
Counting live data is inherently imprecise. There are supposedly some
system tables that can give you rough numbers.
You would be better off figuring out an alternative method to get the data
you desire and stop continually recounting all 5.7M records.
A Trigger driven counter, for insert and d
Hi,
My application has a frequent need to issue a select count(*) on tables.
Some have a large row count. (The example below are from a 5.7 M row; Some
are larger).
Issuing either SELECT COUNT(*) or SELECT COUNT() yelds
a sequential scan on table;
I have browsed catalog tables, digging for a
