From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Chris Hoover <revoohc(at)sermonaudio(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Use of subquery causes seq scan??? |
Date: | 2004-04-20 17:56:32 |
Message-ID: | 20040420175632.GB11203@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Please don't reply to messages to start new threads.
On Tue, Apr 20, 2004 at 10:20:05 -0400,
Chris Hoover <revoohc(at)sermonaudio(dot)com> wrote:
> I need some help. I have a query that refuses to use the provided index and
> is always sequentially scanning causing me large performance headaches. Here
> is the basic situation:
>
> Table A:
> inv_num int
> type char
> .
> .
> .
> pkey (inv_num, type)
> indx(inv_num)
>
> Table B (has the same primary key)
>
> Select *
> from table a
> where inv_num in (select inv_num from table b where ....)
>
> Doing this causes sequential scans of both tables. If I do a set
> enable_seqscan to false before the query, I get an index scan of table b but
> still seq scan table a.
>
> Is there anyway to force table a to use this index (or another) and not
> sequentially scan the table?
>
> I'm running 7.3.4 on RedHat EL 2.1.
IN was slow in 7.3.x and before. The query will probably run much better
as is in 7.4 and above. In 7.3 you want to rewrite it as a join or using
EXISTS.
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-04-20 17:58:18 | Re: Wierd context-switching issue on Xeon |
Previous Message | J. Andrew Rogers | 2004-04-20 17:17:22 | Re: Wierd context-switching issue on Xeon |