On Wed, Feb 21, 2024 at 4:55 PM Richard Guo <guofengli...@gmail.com> wrote: > > > On Tue, Aug 2, 2022 at 4:24 AM Jacob Champion <jchamp...@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