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
