Re: Planner incorrectly choosing seq scan over index scan - Mailing list pgsql-performance

From Tom Lane
Subject Re: Planner incorrectly choosing seq scan over index scan
Date
Msg-id 26292.1122941726@sss.pgh.pa.us
Whole thread Raw
In response to Re: Planner incorrectly choosing seq scan over index scan  (Meetesh Karia <meetesh.karia@gmail.com>)
Responses Re: Planner incorrectly choosing seq scan over index scan
List pgsql-performance
Meetesh Karia <meetesh.karia@gmail.com> writes:
> Sure. The lte_user table is just a collection of users. user_id is assigned=
> uniquely using a sequence. During some processing, we create a candidates=
> table (candidates617004 in our case). This table is usually a temp table.=
> sourceid is a user_id (in this case it is always 617004) and targetid is=20
> also a user_id (2860 distinct values out of 3467). The rest of the=20
> information is either only used in the select clause or not used at all=20
> during this processing.

If you know that sourceid has only a single value, it'd probably be
helpful to call out that value in the query, ie,
    where ... AND c.sourceId = 617004 ...

            regards, tom lane

pgsql-performance by date:

Previous
From: Meetesh Karia
Date:
Subject: Re: Planner incorrectly choosing seq scan over index scan
Next
From: Meetesh Karia
Date:
Subject: Re: Planner incorrectly choosing seq scan over index scan