Re: Slow counting still true?

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(at)postgresql(dot)org [mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of Edson Richter
Sent: Monday, September 17, 2012 9:14 AM
To: pgsql-general(at)postgresql(dot)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(at)tbz-pariv(dot)de<mailto:hv(at)tbz-pariv(dot)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.

Best Wishes,
Chris Travers

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