Message-ID: <4602A15B.7000908@wildenhain.de>
Date: Thu, 22 Mar 2007 16:31:39 +0100
From: Tino Wildenhain <tino@wildenhain.de>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Craig A. James" <cjames@modgraph-usa.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance of count(*)
References: <Pine.LNX.4.62.0703221149210.13747@wr-linux02>
	<200703221208.19358.albert@sedifa.com>
	<Pine.LNX.4.64.0703221323590.1503@ismoli.solenovo.jns>
	<20070322141807.GE11402@mathom.us>
	<46029DE3.9030505@modgraph-usa.com>
In-Reply-To: <46029DE3.9030505@modgraph-usa.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Craig A. James schrieb:
...
> In our case (for a variety of reasons, but this one is critical), we 
> actually can't use Postgres indexing at all -- we wrote an entirely 
> separate indexing system for our data, one that has the following 
> properties:
> 
>  1. It can give out "pages" of information (i.e. "rows 50-60") without
>     rescanning the skipped pages the way "limit/offset" would.
>  2. It can give accurate estimates of the total rows that will be returned.
>  3. It can accurately estimate the time it will take.
> 

Thats certainly not entirely correct. There is no need to store or
maintain this information along with postgres when you can store
and maintain it directly in postgres as well. When you have some
outside application I think I can savely assume you are doing
less updates compared to many reads to have it actually pay out.

So why not store this information in separate "index" and "statistic"
tables? You would have just to join with your real data for retrival.

On top of that, postgres has a very flexible and extensible index
system. This would mean you save on database roundtrips and
double information storage (and the sync problems you certainly
get from it)

Regards
Tino