On 2016/05/12 13:02, Tom Lane wrote:
> Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
>> On 2016/05/11 18:03, Ashutosh Bapat wrote:
>>> A call to GetForeignTable would incur a catalog lookup which means a
>>> catalog table/index scan if corresponding entry is not in the cache.
>>> This is followed by GetUserMapping() which is another catalog access.
>>> That's bound to be expensive than an makeOid(), oidVal() call.
>> Right, but such lookups have been incurred at the planning time (ie,
>> build_simple_rel), and corresponding entries would be in the cache. So,
>> the overhead in that recalculation at the execution time would be not
>> that large in practice. No?
> It's a mistake to assume that execution immediately follows planning.
Yeah, that would not be the case in PREPARE/EXECUTE, right?
> Having said that, I wonder whether you should be thinking less about
> performance and more about correctness. Is a user mapping lookup done
> at plan time still valid at execution, and if so what ensures that?
I think if scanning a foreign join, the user mapping is still valid at
execution, and that is ensured by RevalidateChachedQuery, IIUC.
Best regards,
Etsuro Fujita
