On 2011-01-07 13:55, Lou Picciano wrote:

> One good approach, architecturally, is to prepare _all_ recurring
> procedures within a session at the initiation of the session. Statements
> prepared in this way make use of the PG server's statistics engine and
> optimizer; they actually get faster and faster! Of course, this presumes
> the server is configured to make this all work.

Lou,

as you probably know, prepared statements are used all over the place.
However, this is at the moment done as a security measure only! Libzdb
keeps prepared statements around only until a connection is returned to
the pool. Keeping multiple statements active for a single session would
therefor imply claiming a connection for the duration of that imap session.

This would mean an architectural change; we now pull a connection from
the pool as needed, returning it as soon as possible. This means we're
able to keep the connection pool relatively small, with just a few
connections that are re-used and shared by multiple sessions.

What you're saying is that this is detrimental to performance.

I feel that fixing this would have to be done at the libzdb level, by
allowing a list or vector of statement to 'live' in a connection, until
explicitly cleared or until the connection pool is shutdown.

Let's think about this a little.


-- 
  ________________________________________________________________
  Paul Stevens                                      paul at nfg.nl
  NET FACILITIES GROUP                     GPG/PGP: 1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev

Reply via email to