Re: Cached Query Plans (was: global prepared statements)

Поиск
Список
Период
Сортировка
От Perez
Тема Re: Cached Query Plans (was: global prepared statements)
Дата
Msg-id arturo-B0076D.08440012042008@news.hub.org
обсуждение исходный текст
Ответ на Cached Query Plans (was: global prepared statements)  (PFC <lists@peufeu.com>)
Ответы Re: Cached Query Plans (was: global prepared statements)  ("Dawid Kuroczko" <qnex42@gmail.com>)
Re: Cached Query Plans (was: global prepared statements)  ("Jonah H. Harris" <jonah.harris@gmail.com>)
Список pgsql-hackers
In article <20080411170609.GB4392@alvh.no-ip.org>,> PFC wrote:
> 
> >     So, where to go from that ? I don't see a way to implement this without 
> > a (backwards-compatible) change to the wire protocol, because the clients 
> > will want to specify when a plan should be cached or not. Since the user  
> > should not have to name each and every one of the statements they want to 
> > use plan caching, I see the following choices :
> 


Doesn't Oracle do this now transparently to clients?  That, I believe 
Oracle keeps a statement/plan cache in its shared memory segment (SGA) 
that greatly improves its performance at running queries that don't 
change very often.

From that point of view, Oracle at least sees benefits in doing this.  
From my POV a transparent performance enhancer for all those PHP and 
Rails apps out there.

With plan invalidation in 8.3 this becomes feasible for pgSQL to do as 
well.

-arturo


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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Free Space Map data structure
Следующее
От: "Simone Campora"
Дата:
Сообщение: runtime error on SPGIST, needed help