| From: | Tender Wang <tndrwang(at)gmail(dot)com> |
|---|---|
| To: | Narayanan Venkateswaran <narayananvpostgres(at)gmail(dot)com> |
| Cc: | 303677365(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19800: Wrong results: self-join elimination drops an ORDER BY sort key with GROUPING SETS / CUBE / ROLLUP |
| Date: | 2026-11-11 06:38:06 |
| Message-ID: | CAHewXN=b=1P48C1iFDA6rKqYNxwr6oArB==Z6pcHTPAuS8+4jw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Narayanan Venkateswaran <narayananvpostgres(at)gmail(dot)com> 于2026年10月29日周四 14:41写道：
>
> Approach 2 (Selective SJE check): Instead of skipping SJE query-wide,
> check if the candidate relations
> (toRemove / toKeep) appear in root->parse->groupClause. If neither
> relation is referenced in the grouping
> items, SJE can still safely eliminate the join.
>
Skipping SJE query-wide seems too strict; I'm also thinking about
approach 2. As in the attached v2.
In the attached v2, I collect the relids referenced by the grouping
expressions and skip only an SJE candidate whose toRemove or toKeep
relation overlaps that set. The relid set is computed once in
remove_useless_self_joins(), so the per-candidate check only requires
bitmap overlap tests.
--
Thanks,
Tender Wang
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Skip-sje.patch | text/plain | 4.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-11-11 07:41:49 | Re: BUG #19857: Stats restore rejects empty arrays, losing range and array stats |
| Previous Message | Michael Paquier | 2026-11-11 06:34:57 | Re: BUG #19842: pg_restore_extended_stats() rejects a faithful pg_dump of ANALYZE-produced range expression statisti |