On Mon, May 6, 2024 at 6:54 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > I want to go on record right now as disagreeing with the plan proposed > > in the commit message for the revert commit, namely, committing this > > again early in the v18 cycle. I don't think Tom would have proposed > > reverting this feature unless he believed that it had more serious > > problems than could be easily fixed in a short period of time. I think > > that concern is well-founded, given the number of fixes that were > > committed. It seems likely that the patch needs significant rework and > > stabilization before it gets committed again, and I think it shouldn't > > be committed again without explicit agreement from Tom or one of the > > other committers who have significant experience with the query > > planner. > > FWIW I accept some of the blame here, for not having paid any > attention to the SJE work earlier. I had other things on my mind > for most of last year, and not enough bandwidth to help. > > The main thing I'd like to understand before we try this again is > why SJE needed so much new query-tree-manipulation infrastructure. > I would have expected it to be very similar to the left-join > elimination we do already, and therefore to mostly just share the > existing infrastructure. (I also harbor suspicions that some of > the new code existed just because someone didn't research what > was already there --- for instance, the now-removed replace_varno > sure looks like ChangeVarNodes should have been used instead.)
Thank you for pointing this. This area certainly requires more investigation. > Another thing that made me pretty sad was 8c441c082 (Forbid SJE with > result relation). While I don't claim that that destroyed the entire > use case for SJE, it certainly knocked its usefulness down by many > notches, maybe even to the point where it's not worth putting in the > effort needed to get it to re-committability. So I think we need to > look harder at finding a way around that. Is the concern that > RETURNING should return either old or new values depending on which > RTE is mentioned? If so, maybe the feature Dean has proposed to > allow RETURNING to access old values [1] is a prerequisite to moving > forward. Alternatively, perhaps it'd be good enough to forbid SJE > only when the non-target relation is actually mentioned in RETURNING. Another problem is EPQ. During EPQ, we use most recent tuples for the target relation and snapshot-satisfying tuples for joined relations. And that affects RETURNING as well. If we need to return values for joined relation, that wouldn't be old values, but values of snapshot-satisfying tuple which might be even older. Proper support of this looks like quite amount of work for me. Committing SJE to v18 with this looks challenging. AFICS, going this way would require substantial help from you. ------ Regards, Alexander Korotkov Supabase
