Re: The query cache - first snapshot (long) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: The query cache - first snapshot (long)
Date
Msg-id 200007270336.XAA12552@candle.pha.pa.us
Whole thread Raw
In response to The query cache - first snapshot (long)  (Karel Zak <zakkr@zf.jcu.cz>)
Responses Re: The query cache - first snapshot (long)  (Karel Zak <zakkr@zf.jcu.cz>)
List pgsql-hackers
>  * 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.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: btree split logic is fragile in the presence of lar ge index items
Next
From: Bruce Momjian
Date:
Subject: Re: Hello PL/Python