Re: Performance of count(*)

От: Tino Wildenhain
Тема: Re: Performance of count(*)
Дата: ,
Msg-id: 4603C17E.709@wildenhain.de
(см: обсуждение, исходный текст)
Ответ на: Re: Performance of count(*)  (Michael Stone)
Ответы: Re: Performance of count(*)  (Michael Stone)
Список: 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, )

Michael Stone schrieb:
> On Thu, Mar 22, 2007 at 06:27:32PM +0100, Tino Wildenhain wrote:
>> Craig A. James schrieb:
>>> 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)
>
> Did you read the email before correcting it? From the part you trimmed out:
>
>> The problem is that relational databases were invented before the web
>> and its stateless applications.  In the "good old days", you could
>> connect to a database and work for hours, and in that environment
>> cursors and such work well -- the RDBMS maintains the internal state
>> of the indexing system.  But in a web environment, state information
>> is very difficult to maintain.  There are all sorts of systems that
>> try (Enterprise Java Beans, for example), but they're very complex.

Yes, but actually this is not true. They are not so complex in this
regard. All you have to do is to look in the pg_cursor view if
your cursor is there and if not, create it in your session.
All you need to maintain is the cursor name which maps to your
session + the special query you run. This should be easy
in any web application.

> It sounds like they wrote their own middleware to handle the problem,
> which is basically what you suggested (a "clever pooling web
> application") after saying "wrong".

I read about "building index data outside postgres" which still is
the wrong approach imho.

This discussion is a bit theoretical until we see the actual problem
and the proposed solution here.

Regards
Tino


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

От: "Kevin Grittner"
Дата:
Сообщение: EXISTS optimization
От: "Noah M. Daniels"
Дата:
Сообщение: Strange left outer join performance issue