Re: PERSISTANT PREPARE (another point of view) - Mailing list pgsql-sql

From Milan Oparnica
Subject Re: PERSISTANT PREPARE (another point of view)
Date
Msg-id g62sgn$9b6$1@news.hub.org
Whole thread Raw
In response to Re: PERSISTANT PREPARE (another point of view)  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Responses Re: PERSISTANT PREPARE (another point of view)  (Craig Ringer <craig@postnewspapers.com.au>)
List 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 by date:

Previous
From: Emi Lu
Date:
Subject: Re: Size or efficiency differences "varchar(128) vs. varchar(32)"
Next
From: Craig Ringer
Date:
Subject: Re: PERSISTANT PREPARE (another point of view)