Re: ModifyTable overheads in generic plans - Mailing list pgsql-hackers

From David Rowley
Subject Re: ModifyTable overheads in generic plans
Date
Msg-id CAApHDvqPzsMcKLRpmNpUW97PmaQDTmD7b2BayEPS5AN4LY-0bA@mail.gmail.com
Whole thread Raw
In response to ModifyTable overheads in generic plans  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: ModifyTable overheads in generic plans  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
On Sat, 27 Jun 2020 at 00:36, Amit Langote <amitlangote09@gmail.com> wrote:
> 2. ExecCheckRTPerms(): checks permissions of *all* partitions before
> executing the plan tree, but maybe it's okay to check only the ones
> that will be accessed

I don't think it needs to be quite as complex as that.
expand_single_inheritance_child will set the
RangeTblEntry.requiredPerms to 0, so we never need to check
permissions on a partition.  The overhead of permission checking when
there are many partitions is just down to the fact that
ExecCheckRTPerms() loops over the entire rangetable and calls
ExecCheckRTEPerms for each one.  ExecCheckRTEPerms() does have very
little work to do when requiredPerms is 0, but the loop itself and the
function call overhead show up when you remove the other bottlenecks.

I have a patch somewhere that just had the planner add the RTindexes
with a non-zero requiredPerms and set that in the plan so that
ExecCheckRTPerms could just look at the ones that actually needed
something checked.   There's a slight disadvantage there that for
queries to non-partitioned tables that we need to build a Bitmapset
that has all items from the rangetable.  That's likely a small
overhead, but not free, so perhaps there is a better way.

David



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Fwd: PostgreSQL: WolfSSL support
Next
From: Peter Geoghegan
Date:
Subject: Re: Default setting for enable_hashagg_disk