Re: dblink performance regression

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: fabriziomello(at)gmail(dot)com
Cc: Joe Conway <mail(at)joeconway(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 01:20:08
Message-ID: CAB7nPqQq67sdN0x4OgvZFcaODZ-ans=4xtLY+8s8QR+6bvK6xQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 8, 2013 at 10:16 AM, Fabrízio de Royes Mello
<fabriziomello(at)gmail(dot)com> wrote:
>
>
>
> On Sat, Dec 7, 2013 at 11:07 PM, Joe Conway <mail(at)joeconway(dot)com> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 12/05/2013 07:05 PM, Joe Conway wrote:
>> > On 12/05/2013 06:53 PM, Tom Lane wrote:
>> >> I seem to remember that at some point we realized that the
>> >> encoding ID assignments are part of libpq's ABI and so can't
>> >> practically be changed ever, so the above may be moot. Even so,
>> >> I think it's a bad idea to be depending on pg_encoding_to_char()
>> >> here, given the ambiguity in what it references. It would be
>> >> unsurprising to get build-time or run-time failures on pickier
>> >> platforms, as a consequence of that ambiguity. So I'd still
>> >> recommend comparing integer IDs as above, rather than this.
>> >
>> > Great feedback as always -- thanks! Will make that change.
>>
>> Committed to all active branches.
>>
>
> IMHO is more elegant create a procedure to encapsulate the code to avoid
> redundancy.
Yep, perhaps something like PQsetClientEncodingIfDifferent or similar
would make sense.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-12-08 01:25:45 Re: dblink performance regression
Previous Message Fabrízio de Royes Mello 2013-12-08 01:16:33 Re: dblink performance regression