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

On Tue, Mar 19, 2013 at 1:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Farina <daniel(at)heroku(dot)com> writes:
>> Similar in purpose to cc3f281ffb0a5d9b187e7a7b7de4a045809ff683, but
>> taking into account that a dblink caller may choose to cause arbitrary
>> changes to DateStyle and IntervalStyle. To handle this, it is
>> necessary to use PQparameterStatus before parsing any input, every
>> time. This is avoided in cases that do not include the two
>> problematic types treated -- interval and timestamptz -- by scanning
>> the TupleDesc's types first.
>
> Hm. Is that really a win? Examining the tupdesc wouldn't be free
> either, and what's more, I think you're making false assumptions about
> which types have behavior dependent on the GUCs. You definitely missed
> out on date and plain timestamp, and what of domains over these types?

Yes, I also forgot about arrays, and nested composites in arrays or
nested composites. As soon as recursive types are introduced the scan
is not sufficient for sure: it's necessary to copy every GUC unless
one wants to recurse through the catalogs which feels like a heavy
loss.

I presumed at the time that skimming over the tupdecs to compare a few
Oids would be significantly cheaper than the guts of
PQparameterStatus, which I believe to be a linked list traversal. I
mostly wrote that optimization because it was easy coincidentally from
how I chose to structure the code rather than belief in its absolute
necessity.

And, as you said, I forgot a few types even for the simple case, which
is a bit of a relief because some of the machinery I wrote for the n =
3 case will come in useful for that.

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

I'll take into account these problems and post a new version.

--
fdr