From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | David Grelaud <dgrelaud(at)ideolys(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Why PG uses nested-loop join when no indexes are available? |
Date: | 2016-01-14 15:00:44 |
Message-ID: | 18712.1452783644@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2016-01-14 16:15:04 | Re: pg_dump problem with dropped NOT NULL on child table |
Previous Message | Albe Laurenz | 2016-01-14 13:40:36 | Re: Function error |