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  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Perf Benchmarking and regression.
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: Use %u to print user mapping's umid and userid