From: | Tender Wang <tndrwang(at)gmail(dot)com> |
---|---|
To: | 1105066510(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18568: BUG: Result wrong when do group by on partition table! |
Date: | 2024-08-06 09:27:07 |
Message-ID: | CAHewXNngCmzj8ObeYhYzTj56rDb2HAa-xv-Ekt=BNGJ-9rysGg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tender Wang <tndrwang(at)gmail(dot)com> 于2024年8月6日周二 16:42写道:
> Yeah, I can reproduce $subject on HEAD.
> But I found this when debug into group_by_has_partkey(), as below:
> call nodeToString(groupexprs):
> VAR : varcollid 16384
> call nodeToString(partexpr):
> VAR: varcollid 16384
>
> So the collid of partkey and groupexpr is same, so add check here may not
> fix this issue.
>
> I continue to find out why the collation id of partkey is 16384(e.g.
> case_insensitive). The partkey expr info is
> set in set_baserel_partition_key_exprs(), which it uses
> partkey->parttypcoll[cnt] value not partkey->partcollation value.
>
> And partkey->parttypcoll[cnt] is assigned from pg_attribute , which is the
> column c meta data.
> Should we use partkey->partcollation value? I try to fix that in the
> attached patch. I add your case in the test, and I don't find
> failed regress.
>
The plan seems not what we want, because I forgot to
set enable_partitionwise_aggregate to true.
--
Tender Wang
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Fix-collation-different-between-columan-collation.patch | application/octet-stream | 5.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2024-08-06 11:15:12 | Re: BUG #18569: Memory leak in Postgres Enterprise server |
Previous Message | Aleksander Alekseev | 2024-08-06 09:09:30 | Re: BUG #18568: BUG: Result wrong when do group by on partition table! |