On Tue, Mar 19, 2013 at 2:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Daniel Farina <dan...@heroku.com> writes: >> On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane <t...@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.
Okay, will do, and here's the shorter and less mechanically intensive naive version that I think is the baseline: it doesn't try to optimize out any GUC settings and sets up the GUCs before the two materialization paths in dblink. Something I forgot to ask about is about if an strangely-minded type input function could whack around the GUC as records are being remitted, which would necessitate per-tuple polling of pqParameterStatus (e.g. in the inner loop of a materialization) . That seemed pretty "out there," but I'm broaching it for completeness. I'll see how much of a penalty it is vs. not applying any patch at all next. -- fdr
dblink-guc-sensitive-types-v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
