Re: Questions about btree_gin vs btree_gist for low cardinalitycolumns
В списке pgsql-general по дате отправления:
| От | Thomas Kellerer |
|---|---|
| Тема | Re: Questions about btree_gin vs btree_gist for low cardinalitycolumns |
| Дата | |
| Msg-id | f2af83b5-ec6a-ce7f-7039-e8e91c2ae4c6@gmx.net обсуждение |
| Ответ на | Re: Questions about btree_gin vs btree_gist for low cardinality columns (Will Hartung <willhartung@gmail.com>) |
| Список | pgsql-general |
Will Hartung schrieb am 31.05.2019 um 00:11: > If you have 10M rows with a “STATUS” column of 1 or 2, and an index > on that column, then you have a 2 node index with a bazillion row > pointers. Some systems (I can’t speak to PG in this regard) > degenerate in this kind of use case since the index is more or less > designed to work great in unique identifiers than low cardinality > values. The representation of large record pointer lists may just not > be handled well as edge cases. What I very often do in theses cases is to create two partial indexes: One with "WHERE status = 1" and another with "WHERE STATUS = 2" including _another_ column in the index that I usually use together with the status column in the queries.
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера