Re: [PATCH] Optionally record Plan IDs to track plan changes for a query
От | Sami Imseih |
---|---|
Тема | Re: [PATCH] Optionally record Plan IDs to track plan changes for a query |
Дата | |
Msg-id | CAA5RZ0vM9AsEqvKued2drKZJ1opt3wbYaDbxGzi-khkNzwn7og@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Optionally record Plan IDs to track plan changes for a query (Lukas Fittl <lukas@fittl.com>) |
Список | pgsql-hackers |
>> Separately I've been thinking how we could best have a discussion/review on >> whether the jumbling of specific plan struct fields is correct. I was >> thinking maybe a quick wiki page could be helpful, noting why to jumble/not >> jumble certain fields? > Makes sense. This is a complicated topic. +1 for the Wiki page I started looking at the set of patches and started with v3-0001. For that one, I think we need to refactor a bit more for maintainability/readability. queryjumblefuncs.c now has dual purposes which is the generic node jumbling code and now it also has the specific query jumbling code. That seems wrong from a readability/maintainability perspective. Here are my high-level thoughts on this: 1. rename queryjumblefuncs.c to jumblefuncs.c 2. move the query jumbling related code to parser/analyze.c, since query jumbling occurs there during parsing. 3. Rewrite the comments in the new jumblefuncs.c to make it clear the intention of this infrastructure; that it is used to jumble nodes for query or plan trees. I can work on this if you agree. Regards, Sami
В списке pgsql-hackers по дате отправления: