| From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
|---|---|
| To: | luis(dot)roberto(at)siscobra(dot)com(dot)br, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | James Coleman <jtc331(at)gmail(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: enable_incremental_sort changes query behavior |
| Date: | 2020-11-17 04:23:46 |
| Message-ID: | a833e667-333d-580c-a600-b01ced234184@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| Attachment | Content-Type | Size |
|---|---|---|
| incremental-sort-fix-parallel-safe.patch | text/x-patch | 1.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuro Yamada | 2020-11-17 04:35:07 | Re: list of extended statistics on psql |
| Previous Message | lchch1990@sina.cn | 2020-11-17 03:53:37 | Re: Add statistics to pg_stat_wal view for wal related parameter tuning |