Skip site navigation (1) Skip section navigation (2)

Re: Performance of count(*)

From: Tino Wildenhain <tino(at)wildenhain(dot)de>
To: "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance of count(*)
Date: 2007-03-22 17:27:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Craig A. James schrieb:
> Tino Wildenhain wrote:
>> 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...
>> ...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.
> Whether we store our data inside or outside Postgres misses the point 
> (in fact, most of our data is stored IN Postgres).  It's the code that 
> actually performs the index operation that has to be external to Postgres.
>> On top of that, postgres has a very flexible and extensible index
>> system.
> You guys can correct me if I'm wrong, but the key feature that's missing 
> from Postgres's flexible indexing is the ability to maintain state 
> across queries.  Something like this:
>  select a, b, my_index_state() from foo where ...
>    offset 100 limit 10 using my_index(prev_my_index_state);

Yes, you are wrong :-) The technique is called "CURSOR"
if you maintain persistent connection per session
(e.g. stand allone application or clever pooling webapplication)

If its a naive web application you just store your session
in tables where you can easily maintain the scroll state
as well.


In response to


pgsql-performance by date

Next:From: Michael StoneDate: 2007-03-22 17:39:32
Subject: Re: Performance of count(*)
Previous:From: Craig A. JamesDate: 2007-03-22 17:21:29
Subject: Re: Performance of count(*)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group