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