David Rowley <david.rowley@xxxxxxxxxxxxxxx> writes: > Perhaps separating out enable_nestloop so that it only disables > non-parameterised nested loops, and add another GUC for parameterised > nested loops would be a good thing to do. Likely setting enable_nestloop to > off in production would be a slightly easier decision to make, if that was > the case. > It looks pretty simple to do this, so I hacked it up, and attached it here. > There's no doc changes and I'm not that interested in fighting for this > change, it's more just an idea for consideration. I'm not terribly excited by this idea either. If making such a change actually makes things better for someone consistently, I'd argue that the problem is a mistaken cost estimate elsewhere, and we'd be better off to find and fix the real problem. (There have already been discussions of only believing single-row rowcount estimates when they're provably true, which might help if we can figure out how to do it cheaply enough.) Having said that, if we did split enable_nestloop like this, what I think you'd want to discriminate against is nestloops where the inner rel is not parameterized *by the outer rel*. This test isn't doing that; it will happily accept inner rels that are parameterized by some unrelated rel. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
