Horton

Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian

David Rowley <david.rowley@2ndquadrant.com>

View thread
From: David Rowley <david.rowley@2ndquadrant.com>
To: Phil Florent <philflorent@hotmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-07-16T05:48:54Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Match RelOptInfos by relids not pointer equality.

  2. Fix run-time partition pruning for appends with multiple source rels.

On 16 July 2018 at 16:56, Phil Florent <philflorent@hotmail.com> wrote:

> I should post that in the general section but I am confused by the
> sentence "A parent partition is always going to have a lower relid than
> its children"
>

It's a little confusing since RelOptInfo has a relid field and so does
RangeTblEntry. They both have completely different meanings.  RelOptInfo's
relid is a number starting at 1 and continues in a gapless sequence
increasing by 1 with each RelOptInfo.  These relids are completely internal
to the server and don't appear in the system catalog tables.
RangeTblEntry's relid is what's in pg_class.oid.

I was talking about RelOptInfo's relid.

Using relids starting at 1 is quite convenient for allowing direct array
lookups in various data structures in the planner. However it's also
required to uniquely identify a relation as a single table may appear many
times in a query, so trying to identify them by their oid could be
ambiguous.  Also, some RTEKinds don't have storage, e.g a VALUES() clause.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services