Skip site navigation (1) Skip section navigation (2)

Re: Index scan / Index cond limitation or ?

From: Nikolai Zhubr <n-a-zhubr(at)yandex(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Index scan / Index cond limitation or ?
Date: 2010-10-15 21:00:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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!

> 			regards, tom lane

In response to

pgsql-performance by date

Next:From: Merlin MoncureDate: 2010-10-15 21:06:55
Subject: Re: Stored procedure declared as VOLATILE => no good optimization is done
Previous:From: Kevin GrittnerDate: 2010-10-15 19:24:39
Subject: Re: Stored procedure declared as VOLATILE => no good optimization is done

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group