From: Tom Lane <tgl@sss.pgh.pa.us>
To: PFC <lists@peufeu.com>
Cc: Andrus <kobruleht2@hot.ee>
Cc: Richard Huxton <dev@archonet.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Hash join on int takes 8..114 seconds
Date: Fri, 21 Nov 2008 15:07:02 -0500
Message-ID: <11835.1227298022@sss.pgh.pa.us> (raw)
In-Reply-To: <op.ukze24t0cigqcu@soyouz>
References: <gg1sv3$27fr$1@news.hub.org>
<49253FE1.3070706@archonet.com>
<0205611B528C4C2CBA99AFC64E57D6E8@andrusnotebook>
<op.ukw669uvcigqcu@soyouz>
<75A918DFCF25470FAF96B3FE3D25A38B@andrusnotebook>
<op.ukze24t0cigqcu@soyouz>
PFC <lists@peufeu.com> writes:
> Index on orders_products( product_id ) and orders_products( order_id ):
> => Same plan
> Note that in this case, a smarter planner would use the new index to
> perform a BitmapAnd before hitting the heap to get the rows.
Considering that the query has no constraint on
orders_products.order_id, I'm not sure what you think the extra index is
supposed to be used *for*.
(Well, we could put orders as the outside of a nestloop and then we'd
have such a constraint, but with 30000 orders rows to process that plan
would lose big.)
(And yes, the planner did consider such a plan along the way.
See choose_bitmap_and.)
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, lists@peufeu.com, kobruleht2@hot.ee, dev@archonet.com
Subject: Re: Hash join on int takes 8..114 seconds
In-Reply-To: <11835.1227298022@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox