Re: Performance of count(*)

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Performance of count(*)
Дата
Msg-id b42b73150703221124t1d3430c9j7e4fccfa089c9844@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance of count(*)  (Michael Stone <mstone+postgres@mathom.us>)
Ответы Re: Performance of count(*)  (Michael Stone <mstone+postgres@mathom.us>)
Re: Performance of count(*)  (Tino Wildenhain <tino@wildenhain.de>)
Re: Performance of count(*)  (Michael Stone <mstone+postgres@mathom.us>)
Re: Performance of count(*)  (Michael Stone <mstone+postgres@mathom.us>)
Список pgsql-performance
On 3/22/07, Michael Stone <mstone+postgres@mathom.us> wrote:
> 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.
>
> 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".

Tino was saying that rather that build a complete indexing storage
management solution that lives outside the database, it is better to
do intelligent session management so that you get the simplicity if a
two tier client server system but the scalability of a web app.

Web apps are not necessarily stateless, you just have to be a little
clever about how database connections are opened and closed.  Then you
get all the database stuff that comes along with a persistent
connection (advisory locks, cursors, prepared statements, etc) without
building all kinds of data management into the middleware.

merlin

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

Предыдущее
От: David Brain
Дата:
Сообщение: Re: Potential memory usage issue [resolved]
Следующее
От: Guido Neitzer
Дата:
Сообщение: Re: Performance of count(*)