Re: Planner incorrectly choosing seq scan over index scan

From: Tom Lane
Subject: Re: Planner incorrectly choosing seq scan over index scan
Date: ,
Msg-id: 26292.1122941726@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Planner incorrectly choosing seq scan over index scan  (Meetesh Karia)
Responses: Re: Planner incorrectly choosing seq scan over index scan  (Meetesh Karia)
List: pgsql-performance

Tree view

Planner incorrectly choosing seq scan over index scan  (Meetesh Karia, )
 Re: Planner incorrectly choosing seq scan over index scan  (Tobias Brox, )
  Re: Planner incorrectly choosing seq scan over index scan  (Meetesh Karia, )
 Re: Planner incorrectly choosing seq scan over index scan  (John Arbash Meinel, )
  Re: Planner incorrectly choosing seq scan over index scan  (Meetesh Karia, )
   Re: Planner incorrectly choosing seq scan over index scan  (Tom Lane, )
    Re: Planner incorrectly choosing seq scan over index scan  (Meetesh Karia, )
     Re: Planner incorrectly choosing seq scan over index scan  (Meetesh Karia, )

Meetesh Karia <> 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:

From: Tom Lane
Date:
Subject: Re: Planner incorrectly choosing seq scan over index scan
From: Meetesh Karia
Date:
Subject: Re: Planner incorrectly choosing seq scan over index scan