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 по дате отправления: