Re: Planning time grows exponentially with levels of nested views

Dean Rasheed <dean.a.rasheed@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