Re: Index scan / Index cond limitation or ?

15.10.2010 22:29, Tom Lane:
> Nikolai Zhubr<n-a-zhubr(at)yandex(dot)ru> writes:
>> So, "in (1, 2)" condition is not in Index Cond anymore! Why is that? How
>> can I push it back?
>
> It thinks the indexscan condition is sufficiently selective already.
> An = ANY condition like that will force multiple index searches,
> one for each of the OR'd possibilities, so it's far from "free" to add
> it to the index condition. The planner doesn't think it's worth it.

Aha, ok. It makes sense then. Is this specific case (=ANY in index cond)
described somewhere with reasonable detail? I always try to RTFM first
and most of the time I can find pretty good hints in the regular manual
already (sufficient as a starting point at least) but this specific
topic seems to be somewhat mysterious.

> Perhaps on your real query it is, but there's not much point in
> debating about the behavior on this toy table; without realistic
> table sizes and up-to-date stats it's impossible to say whether that
> choice is correct or not.
>
>> SELECT version();
>> PostgreSQL 8.3.1, compiled by Visual C++ build 1400
>
> You really, really, really ought to be running 8.3.something-newer.
> We didn't put out the last 11 8.3.x bugfix updates just because
> we didn't have anything better to do.

Yes, I know, and I do appreciate the efforts of postgresql devels to
create updates for older versions too.
This server is internal-only (so it does not see any real world yet).
Anyway, I hope to update everything to 9.0.1 soon.

Thank you!

Nikolai
>
> regards, tom lane
>
>