On 2016/05/12 13:02, Tom Lane wrote:
Etsuro Fujita <fujita.ets...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
