Re: pooled prepared statements

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: pooled prepared statements
Дата
Msg-id 491f66a50905131531x774b2a3ds7813b075562cd83f@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pooled prepared statements  (Thomas Finneid <tfinneid@fcon.no>)
Список pgsql-jdbc
I still think you will have multiple prepared statements one per connection regardless of if it uses a procedure, and you would have to prepare the statement on first use and then store it in the session.

Dave

On Wed, May 13, 2009 at 3:52 PM, Thomas Finneid <tfinneid@fcon.no> wrote:

Maybe your right. The query processing takes from 1-10 seconds, so planning it is not a big factor. But when the load becomes higher, as it will be as the data increases, the planning might possibly eat time which could be used elsewhere.

My server, as it is now, is pushing the limits of postgres for my use, so maybe I need to reclaim as much of wasted time as possible...

We'll see.

thomas

Dave Cramer wrote:



On Wed, May 13, 2009 at 10:37 AM, John Lister <john.lister@kickstone.com <mailto:john.lister@kickstone.com>> wrote:

               Probably easier to create a server side function
               instead, then.

           But wouldn't you still have to go through all the planning
           steps within the function for any queries, although i'll
           admit i'm not familiar with Postgresql functions.


       Server-side functions are compiled when installed. Since my
       function would only contain simple queries that are
       parameterized, it would pre-compile well.


While the function may be compiled, the overhead is the same for preparing the statement inside the function. So I don't think it's a huge win.



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

Предыдущее
От: Thomas Finneid
Дата:
Сообщение: Re: pooled prepared statements
Следующее
От: Tanel
Дата:
Сообщение: ResultSet getString() result differs in 8.3 jdbc (compared to 8.1), with "real" type