Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oeOLr-00082i-CJ for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Sep 2022 22:19:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oeOLq-00039w-6e for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Sep 2022 22:19:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oeOLp-00038A-QR for pgsql-hackers@lists.postgresql.org; Fri, 30 Sep 2022 22:19:21 +0000 Received: from mx.zeyos.com ([88.99.153.70]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oeOLn-0000oN-F9 for pgsql-hackers@lists.postgresql.org; Fri, 30 Sep 2022 22:19:20 +0000 Received: from mx.zeyos.com (localhost [127.0.0.1]) by mx.zeyos.com (Postfix) with ESMTP id D75F861A02 for ; Sat, 1 Oct 2022 00:19:17 +0200 (CEST) Authentication-Results: mx.zeyos.com (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=zeyos.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zeyos.com; h= content-transfer-encoding:content-type:content-type:mime-version :references:in-reply-to:message-id:to:from:from:subject:subject :date:date; s=dkim; t=1664576357; x=1665440358; bh=qiO5mqVv+RC9R qN/FvcBgJ/Mgw2vnRKeqCNR4LM60rA=; b=CIX/ppaRUdl2fNHYNW25XbslrKToo 6pSphAkPdXsXZi0DwMA9cyHb0HNVTEejPzKzFoRt99acUexJuPDHldewj7HGOsCS aN+vnSs23CiFNwi2k0dffn5hJaoT9jZqsZ5utCtnh6ZTYrynfUIue9eYrn0bH0/m h/2FXq+6PyVtEc= X-Virus-Scanned: Debian amavisd-new at mx.zeyos.com Received: from mx.zeyos.com ([127.0.0.1]) by mx.zeyos.com (mx.zeyos.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id G1IVn4JKKIJ4 for ; Sat, 1 Oct 2022 00:19:17 +0200 (CEST) Received: from cloud.zeyos.com (static.182.82.88.23.clients.your-server.de [23.88.82.182]) by mx.zeyos.com (Postfix) with ESMTPSA id 7E501619E5; Sat, 1 Oct 2022 00:19:17 +0200 (CEST) Date: Sat, 01 Oct 2022 00:19:16 +0200 Subject: Re: disfavoring unparameterized nested loops From: Benjamin Coutu To: Peter Geoghegan Cc: Tom Lane , Bruce Momjian , PostgreSQL Hackers , Robert Haas , David Rowley Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > Sure, but the model isn't the problem here, really -- not to me. The > problem is that the planner can in some cases choose a plan that is > inherently unreasonable, at least in practical terms. You're talking > about uncertainties. But I'm actually talking about the opposite thing > -- certainty (albeit a limited kind of certainty that applies only to > one narrow set of conditions). =0AI absolutely agree and support your proposal to simply not generate thos= e paths at all unless necessary.=0A=0A> For all I know you might be onto so= mething. But it really seems > independent to me. =0AYeah, I=E2=80=98m sorry if I highjacked this thread for something relate= d but technically different. I just wanted to expand on your proposal by ta= king into account the join depth and also not just talking about unparametr= ized nested loop joins. The research is very clear that the uncertainty is = proportional to the join level, and that is the point I am trying to focus = the discussion on.=0A=0AI really encourage everyone to read the VLDB paper.= BTW, the unnamed proprietary DBMSs in that paper are the 3 big ones from W= ashington, California and NY, in that order.