Re: Index scan / Index cond limitation or ?
От | Nikolai Zhubr |
---|---|
Тема | Re: Index scan / Index cond limitation or ? |
Дата | |
Msg-id | 4CB8C0D2.6000000@yandex.ru обсуждение исходный текст |
Ответ на | Re: Index scan / Index cond limitation or ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
15.10.2010 22:29, Tom Lane: > Nikolai Zhubr<n-a-zhubr@yandex.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 > >
В списке pgsql-performance по дате отправления: