Re: pgsql: Clarify use of temporary tables within partition trees
От | Amit Langote |
---|---|
Тема | Re: pgsql: Clarify use of temporary tables within partition trees |
Дата | |
Msg-id | 8ed3e6e5-225c-cbf9-f8d9-5415df3e7ae1@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: pgsql: Clarify use of temporary tables within partition trees (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-committers |
On 2018/07/04 1:21, Tom Lane wrote: > Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes: >> On Tue, Jul 3, 2018 at 3:20 PM, Amit Langote >> <Langote_Amit_f8@lab.ntt.co.jp> wrote: >>> Maybe because that's what's done for the root parent in a plain >>> inheritance hierarchy, which is always a plain table. In that case, one >>> RTE is for its role as the parent (with rte->inh = true) and another is >>> for its role as a child (with rte->inh = false). The former is processed >>> as an append rel and the latter as a plain rel that will get assigned scan >>> paths such as SeqScan, etc. > >> Yes that's true. > > Yes, that's exactly why there are two RTEs for the parent table in normal > inheritance cases. I concur with the idea that it shouldn't be necessary > to create a child RTE for a partitioning parent table --- we should really > only need the appendrel RTE plus RTEs for tables that will be scanned. > > However, it's not clear to me that this is a trivial change for multilevel > partitioning cases. Do we need RTEs for the intermediate nonleaf levels? > In the abstract, the planner and executor might not need them. But the > code that deals with partitioning constraint management might expect them > to exist. We do need RTEs for *all* parents (non-leaf tables) in a partition tree, each of which we need to process as an append rel (partition pruning is invoked separately for each non-leaf table). What we *don't* need for each of them is the duplicate RTE with inh = false, because we don't need to process them as plain rels. > Another point is that executor-start-time privilege checking is driven > off the RTE list, so we need an RTE for any table that requires priv > checks, so we might need RTEs for intermediate levels just for that. > > Also, IIRC, the planner sets up the near-duplicate RTEs for inheritance > cases so that only one of them is privilege-checked. Yeah, I see in prepunion.c that the child RTE's requiredPerms is set to 0, with the following comment justifying it: "Also, set requiredPerms to zero since all required permissions checks are done on the original RTE." > Be careful that > you don't end up with zero privilege checks on the partition root :-( The original RTE belongs to the partition root and it's already in the range table, so its privileges *are* checked. Thanks, Amit
В списке pgsql-committers по дате отправления: