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: | 4602BC84.8030101@wildenhain.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
Regards
Tino
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Stone | 2007-03-22 17:39:32 | Re: Performance of count(*) |
Previous Message | Craig A. James | 2007-03-22 17:21:29 | Re: Performance of count(*) |