Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 5CA6A1337B47 for ; Thu, 31 Mar 2011 14:26:22 -0300 (ADT) 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 05253-02 for ; Thu, 31 Mar 2011 17:26:14 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from 10610.x.rootbsd.net (10610.x.rootbsd.net [204.109.60.69]) by mail.postgresql.org (Postfix) with ESMTP id 5F2611337B6E for ; Thu, 31 Mar 2011 14:26:14 -0300 (ADT) Received: from [192.168.1.105] (localhost [127.0.0.1]) by 10610.x.rootbsd.net (8.14.3/8.14.3) with ESMTP id p2VHTUYq002051; Thu, 31 Mar 2011 17:29:32 GMT (envelope-from gandalf@shopzeus.com) Message-ID: <4D94B932.3050305@shopzeus.com> Date: Thu, 31 Mar 2011 19:26:10 +0200 From: Laszlo Nagy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: "pgsql-performance@postgresql.org" CC: Daniel Fekete Subject: Why it is using/not using index scan? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201103/379 X-Sequence-Number: 43058 For this query: select pp.id,pp.product_id,pp.selling_site_id,pp.asin from product_price pp where (pp.asin is not null and pp.asin<>'') and (pp.upload_status_id<>1) and pp.selling_site_id in (8,7,35,6,9) and (pp.last_od < 'now'::timestamp - '1 week'::interval ) limit 5000 Query plan is: "Limit (cost=9182.41..77384.80 rows=3290 width=35)" " -> Bitmap Heap Scan on product_price pp (cost=9182.41..77384.80 rows=3290 width=35)" " Recheck Cond: ((last_od < '2011-03-24 13:05:09.540025'::timestamp without time zone) AND (selling_site_id = ANY ('{8,7,35,6,9}'::bigint[])))" " Filter: ((asin IS NOT NULL) AND (asin <> ''::text) AND (upload_status_id <> 1))" " -> Bitmap Index Scan on idx_product_price_last_od_ss (cost=0.00..9181.59 rows=24666 width=0)" " Index Cond: ((last_od < '2011-03-24 13:05:09.540025'::timestamp without time zone) AND (selling_site_id = ANY ('{8,7,35,6,9}'::bigint[])))" For this query: select pp.id,pp.product_id,pp.selling_site_id,pp.asin from product_price pp where (pp.asin is not null and pp.asin<>'') and (pp.upload_status_id<>1) and pp.selling_site_id in (8,7,35,6,9) and (pp.last_od + '1 week'::interval < 'now'::timestamp ) limit 5000 Query plan is: "Limit (cost=0.00..13890.67 rows=5000 width=35)" " -> Seq Scan on product_price pp (cost=0.00..485889.97 rows=174898 width=35)" " Filter: ((asin IS NOT NULL) AND (asin <> ''::text) AND (upload_status_id <> 1) AND ((last_od + '7 days'::interval) < '2011-03-31 13:06:17.460013'::timestamp without time zone) AND (selling_site_id = ANY ('{8,7,35,6,9}'::bigint[])))" The only difference is this: instead of (pp.last_od < 'now'::timestamp - '1 week'::interval ) I have used (pp.last_od + '1 week'::interval < 'now'::timestamp ) First query with index scan opens in 440msec. The second query with seq scan opens in about 22 seconds. So the first one is about 50x faster. My concern is that we are working on a huge set of applications that use thousands of different queries on a database. There are programs that we wrote years ago. The database structure continuously changing. We are adding new indexes and columns, and of course we are upgrading PostgreSQL when a new stable version comes out. There are cases when a change in a table affects 500+ queries in 50+ programs. I really did not think that I have to be THAT CAREFUL with writing conditions in SQL. Do I really have to manually analyze all those queries and "correct" conditions like this? If so, then at least I would like to know if there is a documentation or wiki page where I can learn about "how not to write conditions". I just figured out that I need to put constant expressions on one side of any comparison, if possible. But probably there are other rules I wouldn't think of. Might it be possible to change the optimizer so that it tries to rally constant expressions in the first place? That cannot be bad, right? Thanks, Laszlo