Re: Prepared statements, parameters and logging
От | Csaba Nagy |
---|---|
Тема | Re: Prepared statements, parameters and logging |
Дата | |
Msg-id | 1182770018.13328.63.camel@coppola.muc.ecircle.de обсуждение исходный текст |
Ответ на | Re: Prepared statements, parameters and logging (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: Prepared statements, parameters and logging
|
Список | pgsql-jdbc |
Actually what I'm interested in is to give the server the parameter values for planning or not... before I wanted generic queries so I didn't want the server to see the parameters, and now I want the server to see them before creating the execution plan... am I turning the right knob for this ? Thanks, Csaba. On Mon, 2007-06-25 at 12:54, Dave Cramer wrote: > Csaba, > > They will all be prepared. The threshold is whether to re-use the > prepared statement. > > What you are seeing is the use of unnamed statements. > > If you really want them turned off use protocolVersion=2 > > Dave > On 25-Jun-07, at 6:47 AM, Csaba Nagy wrote: > > > Hi all, > > > > I have a system (postgres 8.1) which was until now running with JDBC > > parameter prepareThreshold=1 so it is always using server side > > prepares > > (we had some trouble in the past if not setting it so). Now we are > > prepared to set this to 0, meaning no server side prepares by > > default... > > > > The problem is that I did the switch and I still see queries which are > > presumably server side prepared (marked with <unnamed> in the log - I > > enabled reporting queries longer than 2 seconds)... > > > > The question is how do I tell for sure from the DB log if a query is > > server side prepared or not ? I was presuming that <unnamed> in the > > log > > means server side prepare, some name like 'C_xyz' means client side > > prepared statement. Is this correct ? > > > > Thanks, > > Csaba. > > > > > > > > ---------------------------(end of > > broadcast)--------------------------- > > TIP 3: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/docs/faq >
В списке pgsql-jdbc по дате отправления: