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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Phil Florent <philflorent@hotmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-07-16T00:55:52Z
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 06:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Also, in the Plan
> representation, I'd suggest avoiding situations where a data structure
> is sometimes a List of Lists of PartitionedRelPruneInfo and sometimes
> just a single-level List.  Saving one ListCell isn't worth the code
> complexity and error-proneness of that.

Thinking about this some more, I don't quite see any reason that the
partitioned_rels for a single hierarchy couldn't just be a Bitmapset
instead of an IntList.

A parent partition is always going to have a lower relid than its
children, so that means that the top level parent will just have the
lowest member in the set.

There's already code in the inheritance_planner which rebuilds the
IntList from a Bitmapset:

while ((i = bms_next_member(partitioned_relids, i)) >= 0)
   partitioned_rels = lappend_int(partitioned_rels, i);

ExecLockNonLeafAppendTables could be made to accept a Bitmapset rather
than a List. In fact, we could probably get rid of the nested loops if
we did it that way.

What do you think?

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