From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Removing redundant grouping columns |
Date: | 2022-12-30 21:02:06 |
Message-ID: | 895775.1672434126@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
>> While we are here, I wonder if we can do the same trick for
>> distinctClause, to cope with cases like
>> select distinct a.x, b.y from a, b where a.x = b.y;
> We do that already, no?
Oh, wait, I see what you mean: we are smart in code paths that rely
on distinct_pathkeys, but not in the hash-based code paths. Right,
that can be fixed the same way. 0001 attached is the same as before,
0002 adds similar logic for the distinctClause.
The plan change in expected/pg_trgm.out is surprising at first
glance, but I believe it's correct: the item that is being
dropped is a parameterless STABLE function, so its value is not
supposed to change for the duration of the scan.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
v3-0001-remove-redundant-GROUP-BY.patch | text/x-diff | 37.9 KB |
v3-0002-remove-redundant-DISTINCT.patch | text/x-diff | 8.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-12-30 21:06:53 | Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler? |
Previous Message | Jeff Davis | 2022-12-30 20:43:04 | Re: New strategies for freezing, advancing relfrozenxid early |