Re: ModifyTable overheads in generic plans
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
tsunakawa.takay@jp.fujitsu.com
Date: 2020-06-29T01:39:01Z
Lists: 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
Commits
-
Comment cleanup for a1115fa07.
- 0d46771eaaf7 14.0 landed
-
Postpone some more stuff out of ExecInitModifyTable.
- a1115fa07823 14.0 landed
-
Postpone some stuff out of ExecInitModifyTable.
- c5b7ba4e67ae 14.0 landed