Postgres Professional
en

Re: Performance of count(*)

От: Tino Wildenhain
Тема: Re: Performance of count(*)
Дата: ,
Msg-id: 4602E8A6.9060600@wildenhain.de
(см: обсуждение, исходный текст)
Ответ на: Re: Performance of count(*)  ("Craig A. James")
Список: pgsql-performance

Скрыть дерево обсуждения

Performance of count(*)  (Andreas Tille, )
 Re: Performance of count(*)  (Andreas Kostyrka, )
  Re: Performance of count(*)  (Andreas Tille, )
   Re: Performance of count(*)  (Andreas Kostyrka, )
    Re: Performance of count(*)  (Michael Fuhr, )
    Re: Performance of count(*)  (Carlos Moreno, )
   Re: Performance of count(*)  ("Luke Lonergan", )
 Re: Performance of count(*)  (Albert Cervera Areny, )
  Re: Performance of count(*)  (, )
   Re: Performance of count(*)  (Bill Moran, )
   Re: Performance of count(*)  (Mario Weilguni, )
   Re: Performance of count(*)  (Michael Stone, )
    Re: Performance of count(*)  (, )
    Re: Performance of count(*)  ("Craig A. James", )
     Re: Performance of count(*)  (Tino Wildenhain, )
      Re: Performance of count(*)  ("Craig A. James", )
       Re: Performance of count(*)  (Tino Wildenhain, )
        Re: Performance of count(*)  (Michael Stone, )
         Re: Performance of count(*)  ("Merlin Moncure", )
          Re: Performance of count(*)  (Michael Stone, )
          Re: Performance of count(*)  (Tino Wildenhain, )
          Re: Performance of count(*)  (Michael Stone, )
          Re: Performance of count(*)  (Michael Stone, )
         Re: Performance of count(*)  (Tino Wildenhain, )
          Re: Performance of count(*)  (Michael Stone, )
           Re: Performance of count(*)  (Tino Wildenhain, )
        Re: Performance of count(*)  ("Craig A. James", )
         Re: Performance of count(*)  (Tino Wildenhain, )
       Re: Performance of count(*)  (Steve Atkins, )
        Re: Performance of count(*)  ("Craig A. James", )
         Re: Performance of count(*)  (Tom Lane, )
          Re: Performance of count(*)  ("Craig A. James", )
           Re: Performance of count(*)  (Tom Lane, )
        Re: Performance of count(*)  (Guido Neitzer, )
         Re: Performance of count(*)  (Steve Atkins, )
     Re: Performance of count(*)  (Brian Hurt, )
      Re: Performance of count(*)  ("Craig A. James", )
 Re: Performance of count(*)  (, )
 Re: Performance of count(*)  ("Merlin Moncure", )
  Re: Performance of count(*)  ("Jonah H. Harris", )
   Re: Performance of count(*)  (Mario Weilguni, )
    Re: Performance of count(*)  (Andreas Kostyrka, )
     Re: Performance of count(*)  (Mario Weilguni, )
  Re: Performance of count(*)  (Michael Stone, ) 
Craig A. James schrieb:
> 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.

Well the cursor is exactly the simple handle to the internal
state of the relational db you are looking for.
Do you really think transferring the whole query-tree, open index
and data files to the client over the network would really improve
the situation?

> As I said earlier, relational technology was invented in an earlier era,
> and hasn't caught up with the reality of modern web apps.

There is nothing modern with todays 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.

Sure it really depends on the application how the best solution
would look like but I'm quite certain, counterfaiting internal
stuff of the underlying relational database in the application
makes more problems then it solves. If you can't handle SQL,
dont use SQL, you can build web applications w/o any relational
database if you want it.

Regards
Tino Wildenhain

В списке pgsql-performance по дате сообщения:

Предыдущее:
От: Michael Stone
Дата:
Сообщение: Re: Performance of count(*)
Следующее:
От: "Matt Smiley"
Дата:
Сообщение: Sunfire X4500 recommendations