Add.

diff --git a/doc/TODO.detail/optimizer b/doc/TODO.detail/optimizer
index 88399e0038ecce251f11f5aca56a09ad7fb3226c..194ca349d32c8348dc489c07bf58ef15a058560d 100644 (file)
--- a/doc/TODO.detail/optimizer
+++ b/doc/TODO.detail/optimizer
@@ -1059,7 +1059,7 @@ From [email protected] Thu Jan 20 18:45:32 2000
 Received: from renoir.op.net ([email protected] [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 [email protected] 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 , [email protected]
+Subject: Re: [HACKERS] Performance on inserts 
+In-reply-to: <[email protected]> 
+References: <[email protected]>
+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: <[email protected]>
+From: Tom Lane 
+X-Mailing-List: [email protected]
+Precedence: bulk
+Sender: [email protected]
+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 [email protected] 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 , [email protected]
+Subject: Re: [HACKERS] Performance on inserts 
+In-reply-to: <[email protected]> 
+References: <[email protected]>
+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: <[email protected]>
+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
+