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-ow...@postgresql.org [mailto:pgsql-general-ow...@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 <h...@tbz-pariv.de<mailto:h...@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. 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
