Re: segfault with incremental sort
От | James Coleman |
---|---|
Тема | Re: segfault with incremental sort |
Дата | |
Msg-id | CAAaqYe9UeEVZyBMUJVFmmKf=WdYBLmG=9oQVayMosQ40rP_FaQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: segfault with incremental sort (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-bugs |
On Mon, Nov 30, 2020 at 8:56 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Nov 25, 2020 at 8:27 PM James Coleman <jtc331@gmail.com> wrote: > > > > On Wed, Nov 25, 2020 at 9:05 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > On Wed, Nov 25, 2020 at 7:57 AM James Coleman <jtc331@gmail.com> wrote: > > > > > > > > > > It is possible but we don't that the context unless subplan is marked > > > parallel-safe. I think if we need to generate parallel-safe plans for > > > correlated queries, we might want to see how the subplan will be > > > marked parallel-safe. > > > > The one possibility I can imagine right now is maintaining some kind > > of flag that marks a subplan as "parallel safe except for params" and > > then recheck the params to see if the specific usage is safe. Does > > something like that seem reasonable? Other than the param, the subplan > > would be marked safe by the existing code. > > > > I don't know. What I remember is it is not easy to check the params to > see if the specific usage is safe for correlated sub-queries as > detecting the level of param was tricky. Basically, whether the param > can be generated below Gather node so that it could be used was a bit > tricky but maybe I had missed something obvious during my analysis. > However, feel free to give it a try. Thanks. I have some work in progress that seems to show promise so far; I hope to post about it in a new thread later this week. James
В списке pgsql-bugs по дате отправления: