| От | Heikki Linnakangas |
|---|---|
| Тема | Re: GIN improvements part2: fast scan |
| Дата | |
| Msg-id | 5320A3D9.1010007@vmware.com обсуждение исходный текст |
| Ответ на | Re: GIN improvements part2: fast scan (Alexander Korotkov <aekorotkov@gmail.com>) |
| Список | pgsql-hackers |
On 03/12/2014 07:42 PM, Alexander Korotkov wrote: > Preparation we do in startScanKey requires knowledge of estimate size of > posting lists/trees. We do this estimate by traversal to leaf pages. I > think gincostestimate is expected to be way more cheap. So, we probably > need so more rough estimate there, don't we? Yeah, maybe. We do something similar for b-tree MIN/MAX currently, but with a lot of keys, it could be a lot more expensive to traverse down to all of them. I wonder if we could easily at least catch the common skewed cases, where e.g the logic of the consistent function is to AND all the keys. The opclass would know that, but we would somehow need to pass down the information to gincostestimate. - Heikki
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера