| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Use %u to print user mapping's umid and userid |
| Date: | 2016-05-12 04:02:13 |
| Message-ID: | 29573.1463025733@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2016-05-12 04:18:43 | Re: Use %u to print user mapping's umid and userid |
| Previous Message | Robert Haas | 2016-05-12 03:52:47 | Re: Perf Benchmarking and regression. |