Hello Svein,

> > I can't believe there is no way to achieve the "explicit IN"
> > performance with a JOIN, a sub-select or anything else.
>
> I generally like using EXISTS, but I don't think it can beat the
> alternatives already mentioned.

Indeed. I tried and it only comes close to the sub-select way.

> And trying to look up values anywhere
> can never beat hardcoding values, it is like trying to access the
> harddisk quicker than the RAM.

Sure, but I thought that with one end of the JOIN/sub-select containing only
the few necessary values, I would have come close to the hardcoding version.

> If this is a query that is executed often and speed is essential, then
> I'd say your only really quick alternative would be to make another
> table and populate it through AFTER INSERT/UPDATE/DELETE triggers from
> your main table. Then you could simply do
> SELECT <whatever> FROM <NewTriggerPopulatedTable>
> whenever you needed these values.

Thanks, I'll keep that idea somewhere. But I'd prefer to avoid
denormalization for now.

Regards.

--
Jerome