From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ioannis Anagnostopoulos <ioannis(at)anatec(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Sequential scan instead of index scan |
Date: | 2012-08-06 15:34:08 |
Message-ID: | 10966.1344267248@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Ioannis Anagnostopoulos <ioannis(at)anatec(dot)com> writes:
> I think this is a pretty good plan and quite quick given the
> size of the table (88Million rows at present). However in real
> life the parameter where I search for msg_id is not an array of
> 3 ids but of 300.000 or more. It is then that the query forgets
> the plan and goes to sequential scan. Is there any way around?
If you've got that many, any(array[....]) is a bad choice. I'd try
putting the IDs into a VALUES(...) list, or even a temporary table, and
then writing the query as a join. It is a serious mistake to think that
a seqscan is evil when you're dealing with joining that many rows, btw.
What you should probably be looking for is a hash join plan.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Midge Brown | 2012-08-06 17:43:13 | Re: slow query, different plans |
Previous Message | Ioannis Anagnostopoulos | 2012-08-06 15:24:57 | Re: Sequential scan instead of index scan |