| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | meetesh(dot)karia(at)alumni(dot)duke(dot)edu |
| Cc: | John Arbash Meinel <john(at)arbash-meinel(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Planner incorrectly choosing seq scan over index scan |
| Date: | 2005-08-02 00:15:26 |
| Message-ID: | 26292.1122941726@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Meetesh Karia <meetesh(dot)karia(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Meetesh Karia | 2005-08-02 07:05:50 | Re: Planner incorrectly choosing seq scan over index scan |
| Previous Message | Meetesh Karia | 2005-08-01 23:56:13 | Re: Planner incorrectly choosing seq scan over index scan |