Daniel Farina <daniel@heroku.com> writes:
> On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane <tgl@sss.pgh.pa.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