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.
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.
In response to
pgsql-hackers by date
|Next:||From: Vladimir Terziev||Date: 2000-07-27 08:36:28|
|Subject: Large text insertion|
|Previous:||From: Zeugswetter Andreas SB||Date: 2000-07-27 08:21:47|
|Subject: AW: TOAST & vacuum|