Re: Planning time grows exponentially with levels of nested views

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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