Re: [GENERAL] Prepared statement performance...

Поиск
Список
Период
Сортировка
От Barry Lind
Тема Re: [GENERAL] Prepared statement performance...
Дата
Msg-id 3D94B17C.3020203@xythos.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Prepared statement performance...  (Aaron Mulder <ammulder@alumni.princeton.edu>)
Список pgsql-jdbc

Dmitry Tkach wrote:
>
> I have to disagree with that too, based on my experience...
> In that application I mentioned in the topic that initiated this
> discussion, the statement, that I have to execute about 30 million times
> looks like
>
> "select * from foo where primary_key=bar"
>
> What could possibly be simpler than that? :-)
> I was surprised to find out however, that in the end the backend turns
> out to have *more* time parsing and planning that query then actually
> executing it :-(
>

I don't disagree that this is a simple query.  But remember that since
the implementation of server side prepare is through the sql interface
with each call to execute this statement you still need to issue the
following sql statement:  execute <name>(bar);  which will still need to
invoke the parser.  Using server side prepared statements doesn't
eliminate all parses.  It isn't true that you can just take the original
  execute time of a statement and assume that with server side prepared
statements the total time will be the same as that, it will be more.

Executing something 30million times will certainly make even a little
improvement for a simple statement like this noticable, but 30million
executes of the same statement certainly isn't the norm.  And I would
suggest it is the type of environment where serverside prepared
statements are the most useful.  I hope you can try the new
functionality and provide us all with real numbers as to how much it helps.

thanks,
--Barry



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

Предыдущее
От: Barry Lind
Дата:
Сообщение: Re: [GENERAL] Prepared statement performance...
Следующее
От: Barry Lind
Дата:
Сообщение: Re: [GENERAL] Prepared statement performance...