Re: disfavoring unparameterized nested loops

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

In response to

Browse pgsql-hackers by date

  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