Horton

Re: Wrong result when enable_partitionwise_join is on if collation of PartitionKey and Column is different.

Amit Langote <amitlangote09@gmail.com>

View thread View on postgr.es
From: Amit Langote <amitlangote09@gmail.com>
To: jian he <jian.universality@gmail.com>
Cc: Junwang Zhao <zhjwpku@gmail.com>, Tender Wang <tndrwang@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: 2024-11-08T09:27:32Z
Lists: pgsql-hackers 
Hi,

On Wed, Nov 6, 2024 at 12:19 PM jian he <jian.universality@gmail.com> wrote:
> looks good to me.
> I didn't find any issue.

Thanks for the review.

> group_by_has_partkey can even cope with:
> EXPLAIN (COSTS OFF, settings)
> SELECT c collate "C" collate case_insensitive collate "C", count(c)
> FROM pagg_tab3 GROUP BY c collate "C" collate case_insensitive collate
> "C" ORDER BY 1;
>
> so i guess in group_by_has_partkey
>                 if (IsA(groupexpr, RelabelType))
>                     groupexpr = ((RelabelType *) groupexpr)->arg;
> should be enough.
>
> not need while loop.
>
>     while (IsA(groupexpr, RelabelType))
>         groupexpr = (Expr *) (castNode(RelabelType, groupexpr))->arg;

Added a comment about that.

Pushed both patches after making changes to 0001 to allow "partial"
partitionwise aggregation after all.  The differences in output with
partial partitionwise aggregation and no partitionwise aggregation
that I mentioned before don't seem to have anything to do with
partitionwise aggregation, but apparently with whether aggregation was
hashed or not.  I confirmed that by turning enable_hashagg on and off
to see the difference.  Changing enable_partitionwise_aggregate for
either of the values of enable_hashagg didn't change the plan.

Thank you all for working on this.

-- 
Thanks, Amit Langote

Commits

  1. Disallow partitionwise join when collations don't match

  2. Disallow partitionwise grouping when collations don't match