Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 4BD872E461C for ; Wed, 6 Feb 2008 12:03:07 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 30456-01-7 for ; Wed, 6 Feb 2008 12:02:59 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id D9E912E4690 for ; Wed, 6 Feb 2008 12:00:39 -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 m16G0Qwf009925; Wed, 6 Feb 2008 11:00:26 -0500 (EST) To: theo@flame.co.za cc: pgsql-performance@postgresql.org Subject: Re: Optimizer : query rewrite and execution plan ? In-reply-to: <1202299962.4274.22.camel@localhost6.localdomain6> References: <60F4687513E90748AE8933DEA5D054E79ACBDE@SLAM0018.match-supermarket.com> <1202298826.4252.972.camel@ebony.site> <1202299962.4274.22.camel@localhost6.localdomain6> Comments: In-reply-to Theo Kramer message dated "Wed, 06 Feb 2008 14:12:42 +0200" Date: Wed, 06 Feb 2008 11:00:26 -0500 Message-ID: <9924.1202313626@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200802/73 X-Sequence-Number: 28615 Theo Kramer writes: > On Wed, 2008-02-06 at 11:53 +0000, Simon Riggs wrote: >> Since the SQL is not your fault and difficult to control, it is an >> argument in favour of an optional planner mode that would perform >> additional checks for redundant clauses of various kinds. The default >> for that would be "off" since most people don't suffer from this >> problem. BO isn't the only SQL generating-client out there, so I think >> this is a fairly wide problem. > I would have to disagree. I spend a lot of time writing code that > generates SQL from a business app and feel strongly that any > optimisation is my responsibility. Disagree with what? If that's your feeling then you'd leave the setting "off", and no harm done. We used to have code that removed duplicate WHERE clauses (check the revision history for prepqual.c). It was taken out because it consumed excessive amounts of planning time without accomplishing a darn thing for most queries. There is no chance that it will be put back in as the only behavior, or even the default behavior, but I can see the reasoning for offering an option as Simon suggests. regards, tom lane