Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL
В списке pgsql-general по дате отправления:
| От | Greg Stark |
|---|---|
| Тема | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |
| Дата | |
| Msg-id | 87d5rxrhhy.fsf@stark.xeocode.com обсуждение исходный текст |
| Ответ на | "Hash index" vs. "b-tree index" (PostgreSQL 8.0) (Ying Lu <ying_lu@cs.concordia.ca>) |
| Список | pgsql-general |
Neil Conway <neilc@samurai.com> writes: > I'm posting mainly because I wasn't sure what to do to avoid false positives in > the case of hash collisions. In the hash AM code it is somewhat awkward to > fetch the pointed-to heap tuple and recheck the scankey.[1] I just did the > first thing that came to mind -- I marked all the hash AM opclasses as "lossy", > so the index qual is rechecked. This works, but suggestions for a better way to > do things would be welcome. I would have thought that would be the only way worth considering. Consider for example a query involving two or more hash indexes and the new bitmap indexscan plan. You don't want to fetch the tuples if you can eliminate them using one of the other indexes. -- greg
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера