Re: The query cache - first snapshot (long)

On Wed, 26 Jul 2000, Bruce Momjian wrote:

> >  * PREPARE/EXECUTE
> >         
> >         - For tests I use query that not use some table (the executor is 
> >         in boredom state), but is difficult for the parser. An example:
> > 
> >         SELECT 'a text ' || (10*10+(100^2))::text || ' next text ' || cast 
> >         (date_part('year', timestamp 'now') AS text );
> >                   
> >         - (10000 * this query):
> > 
> >         standard select:        54 sec
> >         via prepare/execute:     4 sec   (93% better)
> > 
> >         IMHO it is nod bad.
> >  
> >         - For standard query like:
> > 
> >         SELECT u.usename, r.relname FROM pg_class r, pg_user u WHERE 
> >         r.relowner = u.usesysid;
> > 
> >         it is with PREPARE/EXECUTE 10-20% faster.
> > 
> > 
> >  I will *very glad* if someone try and test patch; some discussion is wanted 
> > too.
> 
> Wow, just when I thought we couldnd't get much faster.  That is great.
> 
Very Thanks! 
Your answer is first during one week when this snapshot is outside... I'm a
little worry that it is unconcern for the others.
It is not only PREPARE/EXECUTE it is new SPI_saveplan() design that is
correct to current new Tom's memory design, also here is new SPI 'bykey'
interface for query save/exec --- it can be good for PL those not must run
some internal save-query-management and use self hash tables, ..etc.       
                        Karel