Re: Use of subquery causes seq scan???

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.

In response to

Browse pgsql-performance by date

  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