On Wed, Feb 21, 2024 at 4:55 PM Richard Guo <guofenglinux@gmail.com> wrote:
>
>
> On Tue, Aug 2, 2022 at 4:24 AM Jacob Champion <jchampion@timescale.com> wrote:
>>
>> Once you think you've built up some community support and the patchset
>> is ready for review, you (or any interested party) can resurrect the
>> patch entry by visiting
>>
>> https://commitfest.postgresql.org/38/2266/
>>
>> and changing the status to "Needs Review", and then changing the
>> status again to "Move to next CF". (Don't forget the second step;
>> hopefully we will have streamlined this in the near future!)
>
>
> This patch was returned due to 'lack of interest'. However, upon
> verification, it appears that the reported issue still exists, and the
> proposed fix in the thread remains valid. Hence, resurrect this patch
> after rebasing it on master. I've also written a detailed commit
> message which hopefully can help people review the changes more
> effectively.
The concept looks useful. The SQL statement added in the test looks
cooked though (it outputs data that has same value for two columns
which is equal to primary key of other table - when would somebody do
that?). Is there some real life example of this?
The patch uses restrictclauses as well as EC's. Tom has proposed to
make EC work with outer joins sensibly. Has that happened? Can this
patch leverage it rather than having two loops?
--
Best Wishes,
Ashutosh Bapat