Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

Re: Prepared statements, parameters and logging


  • From: Oliver Jowett <oliver(at)opencloud(dot)com>
  • To: Csaba Nagy <nagy(at)ecircle-ag(dot)com>
  • Cc: Dave Cramer <pg(at)fastcrypt(dot)com>, Postgres JDBC <pgsql-jdbc(at)postgresql(dot)org>
  • Subject: Re: Prepared statements, parameters and logging
  • Date: Tue, 26 Jun 2007 09:40:52 +1200
  • Message-id: <46803664.3060701@opencloud.com> <text/plain>

Csaba Nagy wrote:

Before I was using prepareThreshold='1', and I was seeing only such
entries in the server log:

duration: 5437.499 ms  statement: EXECUTE <unnamed>  [PREPARE:  SELECT
... ]

Note the <unnamed> in the log entry, it was always there for each
statement.

I believe that's logging execution of an unnamed portal, not an unnamed statement. I'm not sure whether the current server logging actually lets you tell whether a named statement was used/reused or not (at least that was one of my complaints about early versions of it -- haven't checked what current versions do).

If the statement name is logged, it'd be something like "S_12345".

After setting prepareThreshold='0', I started getting 2 kinds of log
entries, the ones like above, and the likes:

duration: 2200.570 ms  statement: EXECUTE C_220047  [PREPARE:  SELECT
... ]

Note the C_220047, that's what's changed...

C_.... are portals ("cursors")

If you're using setFetchSize() to avoid pulling in the whole resultset at once, the driver has to use a named statement and named portal regardless of the prepare-threshold setting (because portals are closed when their creating statement is closed, and the unnamed statement gets closed when reused)

-O



Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group