Horton

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

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-17T18:01:25Z
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 2018-Jul-16, David Rowley wrote:

> On 16 July 2018 at 12:55, David Rowley <david.rowley@2ndquadrant.com> wrote:
> > 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.
> 
> Of course, this is not possible since we can't pass a List of
> Bitmapsets to the executor due to Bitmapset not being a node type.

Maybe we can just add a new node type that wraps a lone bitmapset.  The
naive implementation (just print out individual members) should be
pretty straightforward; a more sophisticated one (print out the "words")
may end up more compact or not depending on density, but much harder for
debugging, and probably means a catversion bump when BITS_PER_BITMAPWORD
is changed, so probably not a great idea anyway.

I suppose the only reason we haven't done this yet is nobody has needed
it.  Sounds like its time has come.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services