X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 838109DCBFA for ; Sun, 5 Mar 2006 17:06:51 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 14378-07 for ; Sun, 5 Mar 2006 17:06:52 -0400 (AST) X-Greylist: delayed 00:06:40.186455 by SQLgrey- Received: from peufeu.com (boutiquenumerique.com [82.67.9.10]) by postgresql.org (Postfix) with ESMTP id 6CC3D9DCBB4 for ; Sun, 5 Mar 2006 17:06:46 -0400 (AST) Received: (qmail 9498 invoked from network); 5 Mar 2006 22:00:26 +0100 Received: from boutiquenumerique.com (HELO apollo13) (82.67.9.10) by boutiquenumerique.com with SMTP; 5 Mar 2006 22:00:26 +0100 Date: Sun, 05 Mar 2006 22:00:25 +0100 To: pgsql-performance@postgresql.org Subject: Planner enhancement suggestion. From: PFC Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.51 (Linux, build 1462) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.102 required=5 tests=[AWL=0.102] X-Spam-Score: 0.102 X-Spam-Level: X-Archive-Number: 200603/29 X-Sequence-Number: 17466 Bitmap index scan is bliss. Many thanks to the postgres team ! Now searching in tables with a lot of fields and conditions is no longer a pain. And just a thought : SELECT * FROM table WHERE category IN (1,2,3) ORDER BY price LIMIT 10; Suppose you have an index on category, and another index on price. Depending on the stats postgres has about the values, you'll either get : 0- seq scan + sort 1- Plain or Bitmap Index scan using "category", then sort by "price" 2- Index scan on "price", Filter on "category IN (1,2,3)", no sort. 1 is efficient if the category is rare. Postgres knows this and uses this plan well. Without a LIMIT, option 1 should be preferred. 2 is efficient if the items in the categories 1,2,3 are cheap (close to the start of the index on price). However if the items in question are on the other side of the index, it will index-scan a large part of the table. This can be a big hit. Postgres has no stats about the correlation of "category" and "price", so it won't know when there is going to be a problem. Another option would be interesting. It has two steps : - Build a bitmap using the index on "category" (just like in case 1) so we know which pages on the table have relevant rows - Index scan on "price", but only looking in the heap for pages which are flagged in the bitmap, and then "Recheck Cond" on "category". In other words, do an index scan to get the rows in the right order, but don't bother to check the heap for pages where the bitmap says there are no rows. In the worst case, you still have to run through the entire index, but at least not through the entire table ! It can also speed up some merge joins. What do you think ?