Re: Performance of count(*)

Поиск
Список
Период
Сортировка
От Craig A. James
Тема Re: Performance of count(*)
Дата
Msg-id 4602C02C.2080703@modgraph-usa.com
обсуждение исходный текст
Ответ на Re: Performance of count(*)  (Tino Wildenhain <tino@wildenhain.de>)
Ответы Re: Performance of count(*)  (Tino Wildenhain <tino@wildenhain.de>)
Список 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
modernweb 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
learnthat their problems were more complex than I ever imagined. 

Craig

В списке pgsql-performance по дате отправления:

Предыдущее
От: Michael Stone
Дата:
Сообщение: Re: Performance of count(*)
Следующее
От: Steve Atkins
Дата:
Сообщение: Re: Performance of count(*)