Re: Improving Inner Join Performance - Mailing list pgsql-performance

From Jaime Casanova
Subject Re: Improving Inner Join Performance
Date
Msg-id c2d9e70e0601060726n5f6dfdf4p447c8ad6cec63d1e@mail.gmail.com
Whole thread Raw
In response to Re: Improving Inner Join Performance  ("Andy" <frum@ar-sd.net>)
List pgsql-performance
On 1/6/06, Andy <frum@ar-sd.net> wrote:
> At the moment: o.id_status>3 can have values only 4 and 6. The 6 is around
> 90% from the whole table. This is why seq scan is made.
>
given this if you make id_status > 3 you will never use an index
because you will be scanning 4 and 6 the only values in this field as
you say, and even if there were any other value 6 is 90% of whole
table, so an index for this will not be used...

> Now, depending on the user input the query can have more where fields. For
> example:
> SELECT count(*) FROM orders o
>       INNER JOIN report r ON r.id_order=o.id
>       WHERE o.id_status > 3 AND r.id_zufriden=7
>
here the planner can be more selective, and of course the query is
faster... if you will be loading data load it all then make tests...

but because your actual data the planner will always choose to scan
the entire orders table for o.id_status > 3...

--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator ;)

pgsql-performance by date:

Previous
From: Sebastian Hennebrueder
Date:
Subject: Re: effizient query with jdbc
Next
From: "Jim C. Nasby"
Date:
Subject: Re: improving write performance for logging