Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id B3FBB1337B4A
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu, 11 Nov 2010 13:45:59 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 49834-01
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu, 11 Nov 2010 17:45:52 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 118B1133798E
	for <pgsql-performance@postgresql.org>;
	Thu, 11 Nov 2010 13:45:51 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id oABHjpMd017689;
	Thu, 11 Nov 2010 12:45:51 -0500 (EST)
To: Mladen Gogala <mladen.gogala@vmsinfo.com>
cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	Robert Haas <robertmhaas@gmail.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: anti-join chosen even when slower than old plan 
In-reply-to: <4CDC2424.9010102@vmsinfo.com> 
References: <4CD9663502000025000374B1@gw.wicourts.gov>
	<20961.1289347680@sss.pgh.pa.us>
	<4CDA62C60200002500037512@gw.wicourts.gov>
	<AANLkTi=eNXKEBo5dXJDd4+aHhfmkibH++fqjj12+DA3o@mail.gmail.com>
	<4CDACBBF020000250003755B@gw.wicourts.gov>
	<4CDB7BAA.7020506@vmsinfo.com>
	<4CDBB0A40200002500037571@gw.wicourts.gov>
	<4CDC2424.9010102@vmsinfo.com>
Comments: In-reply-to Mladen Gogala <mladen.gogala@vmsinfo.com>
	message dated "Thu, 11 Nov 2010 12:13:08 -0500"
Date: Thu, 11 Nov 2010 12:45:51 -0500
Message-ID: <17688.1289497551@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201011/153
X-Sequence-Number: 41177

Mladen Gogala <mladen.gogala@vmsinfo.com> writes:
> Again, having an optimizer which will choose the plan completely 
> accurately is, at least in my opinion, less important than having a 
> possibility of manual control, the aforementioned "knobs and buttons" 
> and produce the same plan for the same statement.

More knobs and buttons is the Oracle way, and the end result of that
process is that you have something as hard to use as Oracle.  That's
generally not thought of as desirable in this community.

			regards, tom lane