Re: Use %u to print user mapping's umid and userid
От | Tom Lane |
---|---|
Тема | Re: Use %u to print user mapping's umid and userid |
Дата | |
Msg-id | 29573.1463025733@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Use %u to print user mapping's umid and userid (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: Use %u to print user mapping's umid and userid
|
Список | pgsql-hackers |
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. 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? regards, tom lane
В списке pgsql-hackers по дате отправления: