Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Rushabh Lathia <rushabh.lathia@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Phil Florent <philflorent@hotmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-08-09T04:00:20Z
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.

Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> One reason why we should adapt such a test case is that, in the future, we
> may arrange for make_partitionedrel_pruneinfo(), whose code we just fixed,
> to not be called if we know that run-time pruning is not needed.  It seems
> that that's true for the test added by the commit, that is, it doesn't
> need run-time pruning.

Not following your argument here.  Isn't make_partition_pruneinfo
precisely what is in charge of figuring out whether run-time pruning
is possible?

(See my point in the other thread about Jaime's assertion crash,
that no run-time pruning actually would be possible for that query.
But we got to the assertion failure anyway.)

			regards, tom lane