X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 2B44252924 for ; Fri, 22 Jul 2005 17:49:03 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 99695-04 for ; Fri, 22 Jul 2005 20:49:00 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by svr1.postgresql.org (Postfix) with ESMTP id E5E4C5291E for ; Fri, 22 Jul 2005 17:48:59 -0300 (ADT) Received: by zproxy.gmail.com with SMTP id 8so273449nzo for ; Fri, 22 Jul 2005 13:48:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kma9qgwWfBz22gj+btHcjO2Au/c+gom5VXLMdJnlswp6HfIxDX6S2Ynpp4niOeHO+5Thx1YsIm6x9dG/+Zgt46QXmAKOEb68fcKYefT5tZMr4O5DbHThiImzhzIrL73DjSNf5CWZvPJ4YrUA/XkfAB8K0zzIPH36eFURsQbyQz8= Received: by 10.36.5.19 with SMTP id 19mr34086nze; Fri, 22 Jul 2005 13:48:58 -0700 (PDT) Received: by 10.36.22.20 with HTTP; Fri, 22 Jul 2005 13:48:58 -0700 (PDT) Message-ID: <758d5e7f05072213486919c8f4@mail.gmail.com> Date: Fri, 22 Jul 2005 22:48:58 +0200 From: Dawid Kuroczko Reply-To: Dawid Kuroczko To: Tom Lane Subject: Re: Planner doesn't look at LIMIT? Cc: pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org In-Reply-To: <6440.1122049220@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <758d5e7f0507220210bfa4978@mail.gmail.com> <29473.1122043197@sss.pgh.pa.us> <6440.1122049220@sss.pgh.pa.us> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.611 tagged_above=0 required=5 tests=AWL, FROM_ENDS_IN_NUMS, RCVD_BY_IP X-Spam-Level: X-Archive-Number: 200507/357 X-Sequence-Number: 13598 On 7/22/05, Tom Lane wrote: > > This is quite strange. The nestloop plan definitely should be preferre= d > > in the context of the LIMIT, considering that it has far lower estimate= d > > cost. And it is preferred in simple tests for me. >=20 > After a suitable period of contemplating my navel, I figured out > what is going on here: the total costs involved are large enough that > the still-fairly-high startup cost of the hash is disregarded by > compare_fuzzy_path_costs(), and so the nestloop is discarded as not > having any significant potential advantage in startup time. >=20 > I think that this refutes the original scheme of using the same fuzz > factor for both startup and total cost comparisons, and therefore > propose the attached patch. >=20 > Comments? Works great!!! With LIMIT below 4 000 000 rows (its 47-milion row table) it prefers nested loops, then it starts to introduce merge joins. Regards, Dawid