Hello Dieter,
If you are asking more than about 20% of the rows the optimizer will choose
to do a seq scan and actually that's the right thing to do. On the second
example of yours the rows here less and that's why it chose to go with the
index.
you can force an index scan by changing the optimizer
HiTom,
thanks for your reply. It was the sequential scan on table user (about 1
million rows), which really surprised me. But a sequential scan over 1 million
users seems to be more efficient than an index-Scan for 41.000 rows.
If a execute the query with the ID of a competiton with less partic
Hi Igor,
thanks for the reply. The sequential scan on user_2_competition wasn't my
main-problem. What really suprised me was the sequential scan on table user,
which is a sequential scan over one million rows.
Hash Left Join (cost=111357.64..126222.29 rows=41396 width=42) (actual
time=1982.5
Hi everybody,
in a project I have a performance problem, which I (and my colleagues) don't
understand. It's a simple join between 2 of 3 tables:
table-1: user (id, user_name, ...). This table has about 1 million rows
(999673 rows)
table-2: competition (57 rows)
table-3: user_2_competi
