Re: dblink performance regression

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: "fabriziomello(at)gmail(dot)com" <fabriziomello(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dblink performance regression
Date: 2013-12-08 02:15:57
Message-ID: AA6649D2-A0EA-4620-8263-59C959CFDA2D@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On 2013/12/08, at 10:50, Joe Conway <mail(at)joeconway(dot)com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> 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(dot)paquier(at)gmail(dot)com <mailto:michael(dot)paquier(at)gmail(dot)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.
Agreed as this would change the spec of libpq between minor releases. Sorry for not being clear myself.

> -- 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 ;-)

--
Michael
(Sent from my mobile phone)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Flower 2013-12-08 02:31:33 Re: ANALYZE sampling is too good
Previous Message Fabrízio de Royes Mello 2013-12-08 01:52:15 Re: dblink performance regression