Yes, slowdown was expected :)
I was just interested in cost estimates.
Also did you try to set random_page_cost to 1 if your storage is not hdd.
On Sun, 6 Jun 2021 at 2:44 AM Ayub Khan wrote:
>
> by setting enable_sequence_scan=OFF, the query execution time seems to
> have slowed down even t
by setting enable_sequence_scan=OFF, the query execution time seems to
have slowed down even though the index is being used for left join of
order_offer_map
Hash Left Join (cost=72639.74..8176118.25 rows=19276467 width=293) (actual
time=858.853..3166.994 rows=230222 loops=1)
Hash Cond: (ro.or
thanks Tom.
I was trying to simulate some scenarios to be able to explain how the plan
would change with/without
*Rows Removed by Filter: 73969 * -- by using a different/correct index.
postgres=# \d t
Table "public.t"
Column |Type | Coll
Ayub Khan writes:
> could someone clarify why the LEFT JOIN order_offer_map oom using
> (order_id) in the below query is using sequential scan instead of
> using index on order_id which is defined in order_offer_map table.
Probably because it estimates the hash join to restaurant_order is
faster
