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.
> regards, tom lane
In response to
pgsql-performance by date
|Next:||From: Merlin Moncure||Date: 2010-10-15 21:06:55|
|Subject: Re: Stored procedure declared as VOLATILE => no good
optimization is done|
|Previous:||From: Kevin Grittner||Date: 2010-10-15 19:24:39|
|Subject: Re: Stored procedure declared as VOLATILE => no good optimization is done|