Re: Clean up remove_rel_from_query() after self-join elimination commit
| От | Andrei Lepikhov |
|---|---|
| Тема | Re: Clean up remove_rel_from_query() after self-join elimination commit |
| Дата | |
| Msg-id | 7f6439c7-e5a7-4d0c-82c9-4087794cd9d0@gmail.com обсуждение |
| Ответ на | Clean up remove_rel_from_query() after self-join elimination commit (Richard Guo <guofenglinux@gmail.com>) |
| Ответы |
Re: Clean up remove_rel_from_query() after self-join elimination commit
|
| Список | pgsql-hackers |
On 06/04/2026 10:11, Richard Guo wrote: > Thoughts? Thanks for your efforts! The main goal of the SJE feature was to find common ground within the community - to come up with a solution that everyone could get behind on whether to allow optimisations that address redundant queries and reduce query tree complexity in early planning stages. So, some code roughness was ok. I looked through your code, though maybe not as deeply as this part of the planner deserves. Overall, it looks good, and I didn’t spot any obvious problems, but I do have a few comments. We added some ‘redundant’ checks with future optimisations in mind, so others can rely on these functions to remove tails from query structures or to error if something was left behind. You explicitly write: ‘Each specific caller remains responsible for updating any remaining data structures required by its unique removal logic’ that differs from the initial idea. At the same time, by the end of SJE development, I wasn’t so sure we could invent a universal approach to guarantee the cleanup of the query tree - mostly because of the inherent volatility of the PlannerInfo structure and because we had not agreed to make the parse tree a read-only structure. So, I’m fine with the changes in this patch. -- regards, Andrei Lepikhov, pgEdge
В списке pgsql-hackers по дате отправления: