| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: disfavoring unparameterized nested loops |
| Date: | 2021-06-21 17:01:18 |
| Message-ID: | 1651335.1624294878@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
> I've been thinking about this a bit recently and searching for papers
> talking about this, and but it's not clear to me how to calculate the
> risk (and propagate it through the plan) without making the whole cost
> evaluation way more complicated / expensive :-(
Yeah, a truly complete approach using confidence intervals or the
like seems frighteningly complicated.
> But maybe you have thought about some much simpler approach, addressing
> this sufficiently well?
See my nearby response to Peter. The main case that's distressing me
is the possibility of forcing a hash join even when the outer side
is obviously only one row. If we could avoid that, at least for
large values of "obvious", I'd be far more comfortable.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ranier Vilela | 2021-06-21 17:07:59 | Out-of-bounds (src/backend/utils/misc/queryjumble.c) |
| Previous Message | Tom Lane | 2021-06-21 16:52:39 | Re: disfavoring unparameterized nested loops |