Horton

Re: Properly pathify the union planner

David Rowley <dgrowleyml@gmail.com>

View thread View on postgr.es
From: David Rowley <dgrowleyml@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-26T22:22:53Z
Lists: pgsql-hackers 
On Wed, 27 Mar 2024 at 06:00, Alexander Lakhin <exclusion@gmail.com> wrote:
> SELECT count(*) FROM (
>    WITH q1(x) AS (SELECT 1)
>    SELECT FROM q1 UNION SELECT FROM q1
> ) qu;
>
> TRAP: failed Assert("lg != NULL"), File: "planner.c", Line: 7941, PID: 1133017

Thanks for finding that.

There's something weird going on with the UNION child subquery's
setOperations field. As far as I understand, and from reading the
existing comments, this should only be set for the top-level union.

Because this field is set, it plans the CTE thinking it's a UNION
child and breaks when it can't find a SortGroupClause for the CTE's
target list item.

I'll keep digging. As far as I see the setOperations field is only set
in transformSetOperationStmt(). I'm guessing we must be doing a
copyObject() somewhere and accidentally picking up the parent's
setOperations.

David

Commits

  1. Don't adjust ressortgroupref in generate_setop_child_grouplist()

  2. Don't zero tuple_fraction when planning UNIONs with ORDER BYs

  3. Fix assert failure when planning setop subqueries with CTEs

  4. Allow planner to use Merge Append to efficiently implement UNION

  5. Simplify PathKey checking code

  6. Clarify the 'rows' parameter in create_append_path