Re: Hash join on int takes 8..114 seconds
| От | Tom Lane |
|---|---|
| Тема | Re: Hash join on int takes 8..114 seconds |
| Дата | |
| Msg-id | 11835.1227298022@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Hash join on int takes 8..114 seconds (PFC <lists@peufeu.com>) |
| Ответы |
Re: Hash join on int takes 8..114 seconds
|
| Список | pgsql-performance |
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
В списке pgsql-performance по дате отправления: