Re: Prepared statements, parameters and logging

Поиск
Список
Период
Сортировка
От Oliver Jowett
Тема Re: Prepared statements, parameters and logging
Дата
Msg-id 46803664.3060701@opencloud.com
обсуждение исходный текст
Ответ на Re: Prepared statements, parameters and logging  (Csaba Nagy <nagy@ecircle-ag.com>)
Ответы Re: Prepared statements, parameters and logging  (Csaba Nagy <nagy@ecircle-ag.com>)
Список 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

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Csaba Nagy
Дата:
Сообщение: Re: Prepared statements, parameters and logging
Следующее
От: Oliver Jowett
Дата:
Сообщение: Re: Prepared statements, parameters and logging