Re: pgsql: Clarify use of temporary tables within partition trees

Amit Langote <langote_amit_f8@lab.ntt.co.jp>

From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Michael Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>, pgsql-committers <pgsql-committers@postgresql.org>
Date: 2018-07-04T01:24:15Z
Lists: pgsql-hackers
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



Commits

  1. Remove dead code for temporary relations in partition planning

  2. Clarify use of temporary tables within partition trees

  3. Expand partitioned table RTEs level by level, without flattening.