Re: PERSISTANT PREPARE (another point of view)

Поиск
Список
Период
Сортировка
От Milan Oparnica
Тема Re: PERSISTANT PREPARE (another point of view)
Дата
Msg-id g62sgn$9b6$1@news.hub.org
обсуждение исходный текст
Ответ на Re: PERSISTANT PREPARE (another point of view)  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Ответы Re: PERSISTANT PREPARE (another point of view)  (Craig Ringer <craig@postnewspapers.com.au>)
Список pgsql-sql
I found this link from IBM DB2 developers showing why PERSISTENT PREPARE 
is a good idea and how could it be implemented.

http://www.hoadb2ug.org/Docs/Favero20606.pdf

It seems that main benefit (beside efficiency) is memory.
Having number of connections all with dozens of PREPARED statements 
consumes lot of memory.

If we put these statements in global space (perhaps not even in RAM 
memory until needed) we could reuse optimization plans as well as 
physical space needed to store them.

I also found articles:

http://archives.postgresql.org/pgsql-hackers/2008-04/msg00867.php

and

http://archives.postgresql.org/pgsql-performance/2008-03/msg00480.php

all about users trying to explain PERSISTENT PREPARE (some refer to it 
as global prepare).


There are also some guys who actually made some code for PERSISTENT PREPARE:

http://archives.postgresql.org/pgsql-hackers/2008-03/msg01228.php
and
http://archives.postgresql.org/pgsql-hackers/2008-03/msg01219.php


PEOPLE NEED THIS FEATURE !!! It is not discovering the wheel but it will 
simplify DB programming and even gain some performance.

NONE OF POPULAR SQL DBMS (Oracle, MS SQL, MySQL, Postgre, INTERBASE, 
FIREBIRD) HAVE THIS FEATURE.

WHY ?


В списке pgsql-sql по дате отправления:

Предыдущее
От: Emi Lu
Дата:
Сообщение: Re: Size or efficiency differences "varchar(128) vs. varchar(32)"
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: PERSISTANT PREPARE (another point of view)