Re: Cached Query Plans (was: global prepared statements) - Mailing list pgsql-hackers

From Perez
Subject Re: Cached Query Plans (was: global prepared statements)
Date
Msg-id arturo-B0076D.08440012042008@news.hub.org
Whole thread Raw
In response to Cached Query Plans (was: global prepared statements)  (PFC <lists@peufeu.com>)
Responses 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>)
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Free Space Map data structure
Next
From: "Simone Campora"
Date:
Subject: runtime error on SPGIST, needed help