Re: Bad performance of SELECT ... where id IN (...)

On Mon, Oct 5, 2009 at 1:24 PM, Omar Kilani <omar(dot)kilani(at)gmail(dot)com> wrote:

>
>
> I'm not really sure what the alternatives are -- it never really makes
> sense to get the selectivity for thousands of items in the IN clause.
> I've never seen a different plan for the same query against a DB with
> that patch vs without -- it just takes a huge amount of time longer to
> run without it. :)
>
> But yeah, definitely a hack, and should only be used if needed --
> hopefully there's some sort of official solution on the horizon. :)
>

start using temporary tables, transactions, and joins.
Depending on source of the data (if the source is another query, than just
combine it in one query with join), otherwise create temp table, fill out
with data, and run query with join.
If you do all that in transaction, it will be very fast.

--
GJ