Dean Rasheed <dean.a.rash...@gmail.com> writes:
> I took a look at this and wasn't able to find any way to break it, and
> your argument that it can't really make such rewriter bugs any worse
> makes sense.
Thanks for looking!
> Would it make sense to update the comment prior to copying the subquery?
Yeah, I hadn't touched that yet because the question was exactly about
whether it's correct or not. I think we can shorten it to
* Need a modifiable copy of the subquery to hack on, so that the
* RTE can be left unchanged in case we decide below that we can't
* pull it up after all.
> Out of curiosity, I also tested DML against these deeply nested views
> to see how the pull-up code in the rewriter compares in terms of
> performance, since it does a very similar job. As expected, it's
> O(N^2) as well, but it's about an order of magnitude faster:
Oh good. I hadn't thought to look at that angle of things.
> ... for a one-line change, that's pretty impressive.
Yeah. The problem might get less bad if we get anywhere with the
idea I suggested at [1]. If we can reduce the number of RTEs
in a view's query, then copying it would get cheaper. Still,
not copying it at all is always going to be better. I'll go
ahead and push the patch.
regards, tom lane
[1] https://www.postgresql.org/message-id/697679.1625154303%40sss.pgh.pa.us
