From: | jian he <jian(dot)universality(at)gmail(dot)com> |
---|---|
To: | 狂奔的蜗牛 <1105066510(at)qq(dot)com> |
Cc: | Tender Wang <tndrwang(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>, aleksander <aleksander(at)timescale(dot)com> |
Subject: | Re: BUG #18568: BUG: Result wrong when do group by on partition table! |
Date: | 2024-08-07 15:04:08 |
Message-ID: | CACJufxGeTcuRDM2OEq464bHmeuKiLz21GzFX+p7SDrMqi+9Pug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Aug 7, 2024 at 9:08 PM 狂奔的蜗牛 <1105066510(at)qq(dot)com> wrote:
>
> I readd RelabelType to branch in v5 patch, and add case to cover the code.
>
> In new adding case: `SELECT c collate "C", count(c) FROM pagg_tab3 GROUP BY c collate "C" HAVING count(c) > 1 ORDER BY 1;`
> According to original logic, group_by_has_partkey() will return false, it will lead to cannot do having filter in sub table, the result is correct but the performance is poor.
> Our logic will get better performance.
>
>
> About InvalidOid collation, non-character type's collation is 0(InvalidOid) always.
>
src/test/regress/sql/partition_aggregate.sql
suppose to run with or without ICU, your new test requires ICU,
which will make some buildfarm fail?
put the test to src/test/regress/sql/collate.icu.utf8.sql
seems a little bit of strange.
also. see beginning of partition_aggregate.sql
-- Note: to ensure plan stability, it's a good idea to make the partitions of
-- any one partitioned table in this test all have different numbers of rows.
you may want to adjust the pagg_tab3 partitions rows.
some white space error.
git diff --check
src/backend/optimizer/plan/planner.c:8041: trailing whitespace.
+ * Set collation in group by
clause using COLLATE syntax,
src/backend/optimizer/plan/planner.c:8051: trailing whitespace.
+ }
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2024-08-07 15:48:01 | BUG #18576: Using EXPLAIN (VERBOSE) in information_schema.element_types returns ERROR: failed to find plan for |
Previous Message | Tom Lane | 2024-08-07 14:46:06 | Re: BUG #18573: Analyze command consumes several GB of memory - more than analyzed table size |