If the numbers do not have to be exact the web applications could use the cardinality estimates stored in the system tables.
From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Edson Richter
Sent: Monday, September 17, 2012 9:14 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Slow counting still true?
Em 17/09/2012 06:13, Chris Travers escreveu:
On Mon, Sep 17, 2012 at 1:07 AM, Thomas Guettler <hv@tbz-pariv.de> wrote:
Release 9.2 should increase count(*) performance. Is this wiki page still valid?
http://wiki.postgresql.org/wiki/Slow_Counting
Please update the content.
As I understand it, covering indexes don't currently help with count(*) because indexes can't be traversed in physical order, so it is a matter of trading random disk I/O for a much larger amount of sequential disk I/O.
I'm just a little bit curious, and since count(*) affects a lot my applications (every web system has a paginating feature that depends on count(*) to calculate number of pages without loading everything), I'm also interested in this topic.
The wiki page in question has been updated today, and I see the alert in top of page "Note that the following article only applies to versions of PostgreSQL prior to 9.2. Index-only scans are now implemented."
So seems that traversing indexes for count(*) would be faster on 9.2, right?
AFAIK, for count(*) doesn't matter the order data is stored - just need to load index leaf pages and count from there, right?
Edson
