X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 9C946D1B4E4 for ; Fri, 24 Oct 2003 04:07:08 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 03753-09 for ; Fri, 24 Oct 2003 01:06:37 -0300 (ADT) Received: from smtp.istop.com (dci.doncaster.on.ca [66.11.168.194]) by svr1.postgresql.org (Postfix) with ESMTP id 8EA67D1B515 for ; Fri, 24 Oct 2003 01:06:36 -0300 (ADT) Received: from stark.dyndns.tv (gsstark.mtl.istop.com [66.11.160.162]) by smtp.istop.com (Postfix) with ESMTP id D5AB5369BC; Fri, 24 Oct 2003 00:06:35 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=stark.dyndns.tv ident=foobar) by stark.dyndns.tv with smtp (Exim 3.36 #1 (Debian)) id 1ACtDf-0006Zg-00; Fri, 24 Oct 2003 00:06:35 -0400 To: pgsql-hackers@postgresql.org Subject: Re: 7.4 compatibility question References: <200310231633.h9NGXYk24552@candle.pha.pa.us> In-Reply-To: <200310231633.h9NGXYk24552@candle.pha.pa.us> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 24 Oct 2003 00:06:35 -0400 Message-ID: <87brs71dpw.fsf@stark.dyndns.tv> Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200310/1112 X-Sequence-Number: 45794 Bruce Momjian writes: > Michael Brusser wrote: > > > Optimizer improvements > > => this tells me nothing. I suppose this could be a minor internal code > > tweak, which does not affect me. On the other hand this could be a major > > breakthrough, so now I can run some stupid query which would take > > a week to complete in the previous release. How do I know? > > Yes, this is always very hard to explain. The optimizer itself is > complex, and uses complex terms like merge join and key pruning. It is > hard to explain what queries will be affected, though the basic issue is > that the optimizer will choose a better plan more frequently. One thing that might be worth mentioning is that "WHERE foo IN (subquery)" type queries are much improved. That's a one of the more common complaints about 7.3 and previous and it's one that fairly easy to recognize. -- greg