Re: Use %u to print user mapping's umid and userid

On 2016/05/12 13:02, Tom Lane wrote:
> Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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