From: Bruce Momjian Date: Fri, 19 Jan 2001 22:34:45 +0000 (+0000) Subject: Add. X-Git-Tag: REL7_1~763 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=d4067b53f11a26281b979093d8768a68e504222e;p=postgresql Add. --- diff --git a/doc/TODO.detail/optimizer b/doc/TODO.detail/optimizer index 88399e0038..194ca349d3 100644 --- a/doc/TODO.detail/optimizer +++ b/doc/TODO.detail/optimizer @@ -1059,7 +1059,7 @@ From owner-pgsql-hackers@hub.org Thu Jan 20 18:45:32 2000 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4]) by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA00672 for ; Thu, 20 Jan 2000 19:45:30 -0500 (EST) -Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id TAA01989 for ; Thu, 20 Jan 2000 19:39:15 -0500 (EST) +Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.19 $) with ESMTP id TAA01989 for ; Thu, 20 Jan 2000 19:39:15 -0500 (EST) Received: from localhost (majordom@localhost) by hub.org (8.9.3/8.9.3) with SMTP id TAA00957; Thu, 20 Jan 2000 19:35:19 -0500 (EST) @@ -1919,3 +1919,87 @@ Best Regards, Tiago PS - again: I'm starting, so, some of my comments can be completly dumb. +From pgsql-hackers-owner+M7514@hub.org Sun Oct 15 20:38:12 2000 +Received: from hub.org (hub.org [216.126.84.1]) + by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA18459 + for ; Sun, 15 Oct 2000 19:38:12 -0400 (EDT) +Received: from hub.org.org (localhost [127.0.0.1]) + by hub.org (8.10.1/8.10.1) with SMTP id e9FNaUR59496; + Sun, 15 Oct 2000 19:36:30 -0400 (EDT) +Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154]) + by hub.org (8.10.1/8.10.1) with ESMTP id e9FNYuR58276 + for ; Sun, 15 Oct 2000 19:34:56 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.11.0/8.11.0) with ESMTP id e9FNXaB06046; + Sun, 15 Oct 2000 19:33:36 -0400 (EDT) +To: Bruce Momjian +cc: Jules Bean , + Alfred Perlstein , pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Performance on inserts +In-reply-to: <200010152320.TAA17944@candle.pha.pa.us> +References: <200010152320.TAA17944@candle.pha.pa.us> +Comments: In-reply-to Bruce Momjian + message dated "Sun, 15 Oct 2000 19:20:35 -0400" +Date: Sun, 15 Oct 2000 19:33:36 -0400 +Message-ID: <6043.971652816@sss.pgh.pa.us> +From: Tom Lane +X-Mailing-List: pgsql-hackers@postgresql.org +Precedence: bulk +Sender: pgsql-hackers-owner@hub.org +Status: ORr + +Bruce Momjian writes: +> However, assume tab2.col2 equals 3. I assume this would cause an index +> scan because the executor doesn't know about the most common value, +> right? Is it worth trying to improve that? + +Oh, I see: you are assuming that a nestloop join is being done, and +wondering if it's worthwhile to switch dynamically between seqscan +and indexscan for each scan of the inner relation, depending on exactly +what value is being supplied from the outer relation for that scan. +Hmm. + +Not sure if it's worth the trouble or not. Nestloop is usually a +last-resort join strategy anyway, and is unlikely to be picked when the +tables are large enough to make performance be a big issue. + + regards, tom lane + +From tgl@sss.pgh.pa.us Mon Oct 16 01:48:27 2000 +Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154]) + by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id AAA01602 + for ; Mon, 16 Oct 2000 00:48:26 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id e9G4mu521809; + Mon, 16 Oct 2000 00:48:56 -0400 (EDT) +To: Bruce Momjian +cc: Jules Bean , + Alfred Perlstein , pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Performance on inserts +In-reply-to: <200010160441.AAA01374@candle.pha.pa.us> +References: <200010160441.AAA01374@candle.pha.pa.us> +Comments: In-reply-to Bruce Momjian + message dated "Mon, 16 Oct 2000 00:41:49 -0400" +Date: Mon, 16 Oct 2000 00:48:56 -0400 +Message-ID: <21806.971671736@sss.pgh.pa.us> +From: Tom Lane +Status: OR + +Bruce Momjian writes: +>> So an inner indexscan for tab1 is definitely a possible plan. + +> Yes, that was my point, that a nested loop could easily be involved if +> the joined table has a restriction. Is there a TODO item here? + +More like a "to investigate" --- I'm not sold on the idea that a +dynamic switch in plan types would be a win. Maybe it would be, +but... + +One thing to think about is that it'd be critically dependent on having +accurate statistics. Currently, the planner only places bets on the +average behavior over a whole join. If you make a separate bet on each +scan, then you open up the risk of betting wrong every time, should +your stats be out-of-date or otherwise misleading. + + regards, tom lane +