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(*)
|
Список | 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 по дате отправления: