Re: BUG #18568: BUG: Result wrong when do group by on partition table!
Tender Wang <tndrwang@gmail.com>
From: Tender Wang <tndrwang@gmail.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: 1105066510@qq.com, pgsql-bugs@lists.postgresql.org
Date: 2024-10-23T10:42:40Z
Lists: pgsql-bugs
Tender Wang <tndrwang@gmail.com> 于2024年10月23日周三 14:25写道:
>
>
> And I found some codes only use equal not check the collation, for
> example, in match_expr_to_partition_keys():
> if (equal(lfirst(lc), expr))
> lfirst(lc) is partkeys.
> I thinks other codes assume that the collation of partexprs in RelOptInfo
> is same with pg_partitioned_table. But it is not.
>
>
It seems that only partition pruning logic not only does equal() but also
checks the collation match. I find below codes in
match_clause_to_partition_key():
/*
* Partition key match also requires collation match. There may be
* multiple partkeys with the same expression but different
* collations, so failure is NOMATCH.
*/
if (!PartCollMatchesExprColl(partcoll, opclause->inputcollid))
return PARTCLAUSE_NOMATCH;
Others only do equal(), as far as I know.
I tried the patch I provided in [1], and the regression test cases all
passed.
[1]
https://www.postgresql.org/message-id/CAHewXNnKLrZYG4iqaYw%3DuB3XWRrYRZHo7VtcMsbUEbdbajQg2Q%40mail.gmail.com
--
Thanks,
Tender Wang
Commits
-
Disallow partitionwise grouping when collations don't match
- 90fe6251c816 18.0 landed
- b6484ca9535e 17.1 landed
- dd2f8ebee221 16.5 landed
- 0a620659c549 15.9 landed
- 96f9b29a3e1e 14.14 landed
- ff65f695c0d3 13.17 landed
- 46d9be5efb1a 12.21 landed
-
For partitionwise join, match on partcollation, not parttypcoll.
- 2af28e603319 11.0 cited