Re: NOT EXIST for PREPARE

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: NOT EXIST for PREPARE
Дата
Msg-id CAHyXU0w6rGp_7y+oPERKxMNb2yq3MWvDEJ_oNUVQyUmBDHi0rA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: NOT EXIST for PREPARE  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: NOT EXIST for PREPARE  (Merlin Moncure <mmoncure@gmail.com>)
Re: NOT EXIST for PREPARE  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Список pgsql-hackers
On Wed, Mar 23, 2016 at 7:27 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> With PREPARE IF NOT EXISTS the client is also paying parse and network
> overhead for every time you send that statement. Much better not to send it
> repeatedly in the first place.

How did you determine that?  The client prepares the statement exactly
once.  The problem is there's no easy way to determine if someone else
prepared it first and this patch directly addresses that.

> I think we need to take a step back here and better define the problem
> before stepping in with a proposed solution. Something that avoids the need
> to spam the server with endless copies of the same PREPARE statements would
> be good.

I'm not understanding the objection at all.  You have N client
sessions connecting to the database that all utilize the same named
prepared statement.  A typical pattern is for the application to
prepare them all upon startup, but currently each PREPARE needs to be
wrapped with an exception handler in case someone else prepared it
first.  Having an IF NOT EXISTS decoration simplifies this.  This can
happen both inside and outside of connection pooling scenarios.

merlin



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

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: Optimization for updating foreign tables in Postgres FDW
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: multivariate statistics v14