Date: Fri, 30 Sep 2022 08:44:46 +0200
Subject: Re: disfavoring unparameterized nested loops
From: Benjamin Coutu <ben.coutu@zeyos.com>
To: Peter Geoghegan <pg@bowt.ie>,
	Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	Robert Haas <robertmhaas@gmail.com>,
	David Rowley <dgrowleyml@gmail.com>
Message-ID: <1a5bad8002cee1307653@zeyos.com>
In-Reply-To: 
 <CAH2-Wzmna-=7uK2UixCEB4asrmNsVYi04Yf7PeMZfOhZNV_pqA@mail.gmail.com>
References: 
 <CAH2-Wzmna-=7uK2UixCEB4asrmNsVYi04Yf7PeMZfOhZNV_pqA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/1a5bad8002cee1307653%40zeyos.com>
Precedence: bulk


> In general I suspect that we'd be better off focussing on mitigating
> the impact at execution time. There are at least a few things that we
> could do there, at least in theory. Mostly very ambitious, long term
> things.=0A=0AI think these things are orthogonal. No matter how good the =
cost model ever gets, we will always have degenerate cases.=0AHaving some s=
marts about that in the executor is surely a good thing, but it shouldn't d=
istract us from improving on the planner front.=0A
>=20
> I like the idea of just avoiding unparameterized nested loop joins
> altogether when an "equivalent" hash join plan is available because
> it's akin to an execution-time mitigation, despite the fact that it
> happens during planning. While it doesn't actually change anything in
> the executor, it is built on the observation that we have virtually
> everything to gain and nothing to lose during execution, no matter
> what happens.=0A=0AI agree with you, that those plans are too risky. But =
let's maybe find a more general way of dealing with this.=0A
> Right. Though I am actually sympathetic to the idea that users might
> gladly pay a cost for performance stability -- even a fairly large
> cost. That part doesn't seem like the problem.