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
