Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitd4067b5

Browse files
committed
Add.
1 parent6ce0ed2 commitd4067b5

File tree

1 file changed

+85
-1
lines changed

1 file changed

+85
-1
lines changed

‎doc/TODO.detail/optimizer

Lines changed: 85 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1059,7 +1059,7 @@ From owner-pgsql-hackers@hub.org Thu Jan 20 18:45:32 2000
10591059
Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])
10601060
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA00672
10611061
for <pgman@candle.pha.pa.us>; Thu, 20 Jan 2000 19:45:30 -0500 (EST)
1062-
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id TAA01989 for <pgman@candle.pha.pa.us>; Thu, 20 Jan 2000 19:39:15 -0500 (EST)
1062+
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.19 $) with ESMTP id TAA01989 for <pgman@candle.pha.pa.us>; Thu, 20 Jan 2000 19:39:15 -0500 (EST)
10631063
Received: from localhost (majordom@localhost)
10641064
by hub.org (8.9.3/8.9.3) with SMTP id TAA00957;
10651065
Thu, 20 Jan 2000 19:35:19 -0500 (EST)
@@ -1919,3 +1919,87 @@ Best Regards,
19191919
Tiago
19201920
PS - again: I'm starting, so, some of my comments can be completly dumb.
19211921

1922+
From pgsql-hackers-owner+M7514@hub.org Sun Oct 15 20:38:12 2000
1923+
Received: from hub.org (hub.org [216.126.84.1])
1924+
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA18459
1925+
for <pgman@candle.pha.pa.us>; Sun, 15 Oct 2000 19:38:12 -0400 (EDT)
1926+
Received: from hub.org.org (localhost [127.0.0.1])
1927+
by hub.org (8.10.1/8.10.1) with SMTP id e9FNaUR59496;
1928+
Sun, 15 Oct 2000 19:36:30 -0400 (EDT)
1929+
Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
1930+
by hub.org (8.10.1/8.10.1) with ESMTP id e9FNYuR58276
1931+
for <pgsql-hackers@postgresql.org>; Sun, 15 Oct 2000 19:34:56 -0400 (EDT)
1932+
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
1933+
by sss.pgh.pa.us (8.11.0/8.11.0) with ESMTP id e9FNXaB06046;
1934+
Sun, 15 Oct 2000 19:33:36 -0400 (EDT)
1935+
To: Bruce Momjian <pgman@candle.pha.pa.us>
1936+
cc: Jules Bean <jules@jellybean.co.uk>,
1937+
Alfred Perlstein <bright@wintelcom.net>, pgsql-hackers@postgresql.org
1938+
Subject: Re: [HACKERS] Performance on inserts
1939+
In-reply-to: <200010152320.TAA17944@candle.pha.pa.us>
1940+
References: <200010152320.TAA17944@candle.pha.pa.us>
1941+
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
1942+
message dated "Sun, 15 Oct 2000 19:20:35 -0400"
1943+
Date: Sun, 15 Oct 2000 19:33:36 -0400
1944+
Message-ID: <6043.971652816@sss.pgh.pa.us>
1945+
From: Tom Lane <tgl@sss.pgh.pa.us>
1946+
X-Mailing-List: pgsql-hackers@postgresql.org
1947+
Precedence: bulk
1948+
Sender: pgsql-hackers-owner@hub.org
1949+
Status: ORr
1950+
1951+
Bruce Momjian <pgman@candle.pha.pa.us> writes:
1952+
> However, assume tab2.col2 equals 3. I assume this would cause an index
1953+
> scan because the executor doesn't know about the most common value,
1954+
> right? Is it worth trying to improve that?
1955+
1956+
Oh, I see: you are assuming that a nestloop join is being done, and
1957+
wondering if it's worthwhile to switch dynamically between seqscan
1958+
and indexscan for each scan of the inner relation, depending on exactly
1959+
what value is being supplied from the outer relation for that scan.
1960+
Hmm.
1961+
1962+
Not sure if it's worth the trouble or not. Nestloop is usually a
1963+
last-resort join strategy anyway, and is unlikely to be picked when the
1964+
tables are large enough to make performance be a big issue.
1965+
1966+
regards, tom lane
1967+
1968+
From tgl@sss.pgh.pa.us Mon Oct 16 01:48:27 2000
1969+
Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
1970+
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id AAA01602
1971+
for <pgman@candle.pha.pa.us>; Mon, 16 Oct 2000 00:48:26 -0400 (EDT)
1972+
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
1973+
by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id e9G4mu521809;
1974+
Mon, 16 Oct 2000 00:48:56 -0400 (EDT)
1975+
To: Bruce Momjian <pgman@candle.pha.pa.us>
1976+
cc: Jules Bean <jules@jellybean.co.uk>,
1977+
Alfred Perlstein <bright@wintelcom.net>, pgsql-hackers@postgresql.org
1978+
Subject: Re: [HACKERS] Performance on inserts
1979+
In-reply-to: <200010160441.AAA01374@candle.pha.pa.us>
1980+
References: <200010160441.AAA01374@candle.pha.pa.us>
1981+
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
1982+
message dated "Mon, 16 Oct 2000 00:41:49 -0400"
1983+
Date: Mon, 16 Oct 2000 00:48:56 -0400
1984+
Message-ID: <21806.971671736@sss.pgh.pa.us>
1985+
From: Tom Lane <tgl@sss.pgh.pa.us>
1986+
Status: OR
1987+
1988+
Bruce Momjian <pgman@candle.pha.pa.us> writes:
1989+
>> So an inner indexscan for tab1 is definitely a possible plan.
1990+
1991+
> Yes, that was my point, that a nested loop could easily be involved if
1992+
> the joined table has a restriction. Is there a TODO item here?
1993+
1994+
More like a "to investigate" --- I'm not sold on the idea that a
1995+
dynamic switch in plan types would be a win. Maybe it would be,
1996+
but...
1997+
1998+
One thing to think about is that it'd be critically dependent on having
1999+
accurate statistics. Currently, the planner only places bets on the
2000+
average behavior over a whole join. If you make a separate bet on each
2001+
scan, then you open up the risk of betting wrong every time, should
2002+
your stats be out-of-date or otherwise misleading.
2003+
2004+
regards, tom lane
2005+

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp