Re: Best way to scan on-disk bitmaps
От | Tom Lane |
---|---|
Тема | Re: Best way to scan on-disk bitmaps |
Дата | |
Msg-id | 12737.1115934006@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Best way to scan on-disk bitmaps ("Victor Y. Yegorov" <viy@mits.lv>) |
Ответы |
Re: Best way to scan on-disk bitmaps
Re: Best way to scan on-disk bitmaps Re: Best way to scan on-disk bitmaps |
Список | pgsql-hackers |
"Victor Y. Yegorov" <viy@mits.lv> writes: > If I have on-disk bitmap > ON (a, b, c) > will the planner pick an index scan for > WHERE a = 42 AND b = 'foo' > (i.e. only part of the index attributes are involved)? Any modifications > needed to achieve this functionality? Hmm. That particular case will work, but the planner believes that only consecutive columns in the index are usable --- that is, if you have quals for a and c but not for b, it will think that the condition for c isn't usable with the index. This is true for btree and gist indexes, so I suppose we'd need to introduce a pg_am column that tells what to do. [ thinks some more ... ] Plan B would be to remove that restriction and teach btree and gist to cope. While a btree couldn't use a nonconsecutive restriction as part of its where-to-scan logic, I don't see any good reason why it couldn't still perform the test before returning the TID, thus possibly saving a trip to the heap. Offhand it seems this should be true of gist as well, but I don't know that code well enough to be sure. regards, tom lane
В списке pgsql-hackers по дате отправления: