| From: | jian he <jian(dot)universality(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, Zhang Mingli <zmlpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Remove useless GROUP BY columns considering unique index |
| Date: | 2024-12-02 04:22:09 |
| Message-ID: | CACJufxHPRYVpXsjNKkeu0NYdLnGY7eoB1thtuUiGGrSE4+fz0w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Nov 29, 2024 at 5:20 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> The reason I don't think is possible is that we have no infrastructure
> that allows us to tag functions or operators so that non-null input(s)
> mean non-null outputs. We only have strict, which means null input
> means null output. That's the opposite of what we'd need. It might
> only be possible with a NULLS NOT DISTINCT index.
>
Thank you for pointing out "non-null input(s) mean non-null outputs" .
I didn't think about it at all.
regarding v10.
you placed remove_useless_groupby_columns right after add_base_rels_to_query
makes so much sense.
so we can be safely use cached RelOptInfo->indexlist, RelOptInfo->notnullattnums
overall it didn't find any issue.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2024-12-02 06:17:09 | Re: Memory leak in WAL sender with pgoutput (v10~) |
| Previous Message | Andrei Lepikhov | 2024-12-02 04:18:42 | Re: Remove useless GROUP BY columns considering unique index |