Re: The query cache - first snapshot (long)

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: The query cache - first snapshot (long)
Дата
Msg-id 200007270336.XAA12552@candle.pha.pa.us
обсуждение исходный текст
Ответ на The query cache - first snapshot (long)  (Karel Zak <zakkr@zf.jcu.cz>)
Ответы Re: The query cache - first snapshot (long)  (Karel Zak <zakkr@zf.jcu.cz>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: btree split logic is fragile in the presence of lar ge index items
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Hello PL/Python