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: | 2007-06-25 21:40:52 |
Message-ID: | 46803664.3060701@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2007-06-25 22:07:44 | Re: Prepared statements, parameters and logging |
Previous Message | Bady, Brant RBCM:EX | 2007-06-25 16:18:37 | Can MD5 sums be posted for the downloadable files? |