Re: Performance of count(*)

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.

Regards
Tino