| От | Tom Lane |
|---|---|
| Тема | Re: Query planner plans very inefficient plans |
| Дата | |
| Msg-id | 16644.1056999926@sss.pgh.pa.us обсуждение |
| Ответ на | Query planner plans very inefficient plans ("Robert Wille" <a2om6sy02@sneakemail.com>) |
| Список | pgsql-performance |
"Robert Wille" <a2om6sy02@sneakemail.com> writes:
> select * from image natural join ancestry where ancestorid=1000000 and
> (state & 7::bigint) = 0::bigint;
The planner is not going to have any statistics that allow it to predict
the number of rows satisfying that &-condition, and so it's unsurprising
if its off-the-cuff guess has little to do with reality.
I'd recommend skipping any cute tricks with bit-packing, and storing the
state (and any other values you query frequently) as its own column, so
that the query looks like
select * from image natural join ancestry where ancestorid=1000000 and
state = 0;
ANALYZE should be able to do a reasonable job with a column that has 8
or fewer distinct values ...
regards, tom lane
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера