From: | "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com> |
---|---|
To: | Tino Wildenhain <tino(at)wildenhain(dot)de> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance of count(*) |
Date: | 2007-03-22 17:43:08 |
Message-ID: | 4602C02C.2080703@modgraph-usa.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tino Wildenhain wrote:
>> 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)
That's my whole point: If relational databases had a simple mechanism for storing their internal state in an external application, the need for cursors, connection pools, and all those other tricks would be eliminated.
As I said earlier, relational technology was invented in an earlier era, and hasn't caught up with the reality of modern web apps.
> If its a naive web application you just store your session
> in tables where you can easily maintain the scroll state
> as well.
One thing I've learned in 25 years of software development is that people who use my software have problems I never imagined. I've been the one who was naive when I said similar things about my customers, and was later embarrassed to learn that their problems were more complex than I ever imagined.
Craig
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Atkins | 2007-03-22 17:53:24 | Re: Performance of count(*) |
Previous Message | Michael Stone | 2007-03-22 17:39:32 | Re: Performance of count(*) |