Re: pgsql: Clarify use of temporary tables within partition trees - Mailing list pgsql-committers

From Amit Langote
Subject Re: pgsql: Clarify use of temporary tables within partition trees
Date
Msg-id 8ed3e6e5-225c-cbf9-f8d9-5415df3e7ae1@lab.ntt.co.jp
Whole thread Raw
In response to Re: pgsql: Clarify use of temporary tables within partition trees  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Amit Langote
Date:
Subject: Re: pgsql: Clarify use of temporary tables within partition trees
Next
From: Michael Paquier
Date:
Subject: pgsql: Remove dead code for temporary relations in partition planning