Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Farina <daniel@heroku.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2013-03-19T21:41:13Z
Lists: pgsql-hackers
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix postgres_fdw's issues with inconsistent interpretation of data values.
- cc3f281ffb0a 9.3.0 cited