| От | Tomas Vondra |
|---|---|
| Тема | Re: enable_incremental_sort changes query behavior |
| Дата | |
| Msg-id | a833e667-333d-580c-a600-b01ced234184@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: enable_incremental_sort changes query behavior (luis.roberto@siscobra.com.br) |
| Ответы |
Re: enable_incremental_sort changes query behavior
|
| Список | pgsql-hackers |
Hmm, I missed that other thread. That indeed seems like a bug in the same area already tweaked by ebb7ae839d033d0f2 for similar cases. The attached patch fixes this simply by adding is_parallel_safe to get_useful_pathkeys_for_relation - that does fix the reproducer, but I'm not entirely sure that's the right place. Maybe it should be done in find_em_expr_usable_for_sorting_rel (which might make a difference if an EC clause can contain a mix of parallel safe and unsafe expressions). Or maybe we should do it in the caller (which would allow using get_useful_pathkeys_for_relation in contexts not requiring parallel safety in the future). Anyway, while this is not an "incremental sort" bug, it seems like the root cause is the same as for ebb7ae839d033d0f2 - one of the incremental sort patches started considering sorting below gather nodes, not realizing these possible consequences. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера