Re: dblink performance regression

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: dblink performance regression
Дата
Msg-id 52D8336B.1080501@agliodbs.com
обсуждение исходный текст
Ответ на dblink performance regression  (Joe Conway <mail@joeconway.com>)
Ответы Re: dblink performance regression  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
On 12/07/2013 05:50 PM, Joe Conway wrote:
> On 12/07/2013 05:41 PM, Fabrízio de Royes Mello wrote:
>
>> On Sat, Dec 7, 2013 at 11:20 PM, Michael Paquier
>> <michael.paquier@gmail.com <mailto:michael.paquier@gmail.com>>
>> wrote:
>>>>
>>>> IMHO is more elegant create a procedure to encapsulate the code
>>>> to avoid redundancy.
>>> Yep, perhaps something like PQsetClientEncodingIfDifferent or
>>> similar would make sense.
>
>> Well I think at this first moment we can just create a procedure
>> inside the dblink contrib and not touch in libpq.
>
> Maybe a libpq function could be done for 9.4, but not for back branches.
>
> I don't think it makes sense to create a new function in dblink either
> -- we're only talking about two lines of added redundancy which is
> less lines of code than a new function would add. But if we create
> PQsetClientEncodingIfDifferent() (or whatever) we can remove those
> extra lines in 9.4 ;-)

Hey, since we're about to do 9.3.3: was this patch ever committed?


--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCH] Relocation of tablespaces in pg_basebackup