Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables)
Date: 2013-03-19 21:41:13
Message-ID: 12848.1363729273@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Farina <daniel(at)heroku(dot)com> writes:
> On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'd be inclined to eat the cost of calling PQparameterStatus every time
>> (which won't be that much) and instead try to optimize by avoiding the
>> GUC-setting overhead if the current value matches the local setting.
>> But even that might be premature optimization. Did you do any
>> performance testing to see if there was a problem worth avoiding?

> Nope; should I invent a new way to do that, or would it be up to
> commit standard based on inspection alone? I'm okay either way, let
> me know.

Doesn't seem that hard to test: run a dblink query that pulls back a
bunch of data under best-case conditions (ie, local not remote server),
and time it with and without the proposed fix. If the difference
is marginal then it's not worth working hard to optimize.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Farina 2013-03-19 22:06:29 Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables)
Previous Message Greg Smith 2013-03-19 21:28:49 Re: Enabling Checksums