Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 5406A2F4276 for ; Wed, 21 Mar 2012 07:38:06 -0300 (ADT) Received: from mx.ac-sw.com ([109.202.7.82] helo=gw.ac-sw.com) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SAIva-0003TP-3l for pgsql-hackers@postgresql.org; Wed, 21 Mar 2012 10:38:05 +0000 Received: from begemot.ac-sw.com (ws-4-002.ac-sw.lcl [192.168.4.2]) by gw.ac-sw.com (Postfix) with ESMTP id 58B1D39C019; Wed, 21 Mar 2012 16:37:46 +0600 (NOVT) Received: from localhost (localhost [127.0.0.1]) by begemot.ac-sw.com (Postfix) with ESMTP id 9600C1600099F; Wed, 21 Mar 2012 17:37:47 +0700 (NOVT) X-Virus-Scanned: Debian amavisd-new at begemot.ac-sw.com Received: from begemot.ac-sw.com ([127.0.0.1]) by localhost (begemot.ac-sw.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG5fHDEELDmc; Wed, 21 Mar 2012 17:37:38 +0700 (NOVT) Received: from [192.168.4.71] (gw.ac-sw.com [109.202.7.82]) (Authenticated sender: fozzy) by begemot.ac-sw.com (Postfix) with ESMTPSA id CBD2A16000ACD; Wed, 21 Mar 2012 17:37:37 +0700 (NOVT) Message-ID: <4F69B08E.8040407@ac-sw.com> Date: Wed, 21 Mar 2012 17:42:22 +0700 From: =?UTF-8?B?0JTQvNC40YLRgNC40Lk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Tom Lane Cc: Pg Hackers Subject: Re: Postgres 8.4 planner question - bad plan, good plan for almost same queries. References: <4F683BFC.5030400@ac-sw.com> <26101.1332258220@sss.pgh.pa.us> In-Reply-To: <26101.1332258220@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201203/1343 X-Sequence-Number: 205225 > I think the reason the planner isn't too bright about this case is > http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=cd1f0d04bf06938c0ee5728fc8424d62bcf2eef3 > ie, it won't do IN/EXISTS pullup below a NOT EXISTS. > > HEAD is better, thanks to commit > 0816fad6eebddb8f1f0e21635e46625815d690b9, but of course there is no > chance at all of back-patching the planner changes that depends on. I found that it works fine for [NOT] EXISTS if I just fold query inside into "select 1 from (...) vv". With my provided query, it uses seqscan for both EXISTS/NOT EXISTS without folding, and index scan with it. Okay, it's easier for me to make automatic subquery folding. Regards, Dmitry