Re: dblink performance regression

From: Joe Conway <mail(at)joeconway(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>, <fabriziomello(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: 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: 2014-01-16 20:44:26
Message-ID: 1439ccc3040.274a.4c0943eccb4f26345b421b6bb9592ac9@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

yes

Joe

Sent with AquaMail for Android
http://www.aqua-mail.com

On January 16, 2014 2:32:55 PM Josh Berkus <josh(at)agliodbs(dot)com> wrote:

> 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(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.
> > 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Theodore Ts'o 2014-01-16 21:10:40 Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Previous Message Marko Tiikkaja 2014-01-16 20:40:03 Re: Display oprcode and its volatility in \do+