From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Use %u to print user mapping's umid and userid |
Date: | 2016-05-12 03:18:39 |
Message-ID: | 481d5b6f-7017-5e33-7926-d9139284bd8e@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016/05/11 18:03, Ashutosh Bapat wrote:
> On Wed, May 11, 2016 at 1:34 PM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp <mailto:fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>> wrote:
> On 2016/05/11 16:49, Ashutosh Bapat wrote:
>
> The patch is calculating user mapping when it's readily available
> through RelOptInfo::fdw_private. That incurs a catalog lookup
> unnecessarily. Instead, can we add new function makeOid, oidVal
> on the
> lines of makeInteger and intVal to store and retrieve an OID
> resp. and
> also corresponding print function? It might be helpful in future.
> That might be an idea, but is the overhead in that re-calculation so
> large?
> 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?
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-05-12 03:48:39 | Re: Vacuum Full by Scheme |
Previous Message | Rajeev rastogi | 2016-05-12 03:16:01 | Re: Academic help for Postgres |