Re: [PATCH] Improve ability to display optimizer analysis using OPTIMIZER_DEBUG
От | Ankit Kumar Pandey |
---|---|
Тема | Re: [PATCH] Improve ability to display optimizer analysis using OPTIMIZER_DEBUG |
Дата | |
Msg-id | 35a06490-6078-bb91-a87f-2f9b259845e1@gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Improve ability to display optimizer analysis using OPTIMIZER_DEBUG (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: [PATCH] Improve ability to display optimizer analysis using OPTIMIZER_DEBUG
Re: [PATCH] Improve ability to display optimizer analysis using OPTIMIZER_DEBUG |
Список | pgsql-hackers |
On 03/01/23 08:38, David Rowley wrote: > I'm with Tom on this. I've never once used this feature to try to > figure out why a certain plan was chosen or not chosen. > > I'd really rather not see us compiling all that debug code in by > default unless it's actually going to be useful to a meaningful number > of people. > Okay this makes sense. > > Do you actually have a need for this or are you just trying to tick > off some TODO items? > I would say Iatter but reason I picked it up was more on side of learning optimizer better. Currently, I am left with explain analyze which does its job but for understanding internal working of optimizer, there are not much alternatives. Again, if I know where to put breakpoint, I could see required path/states but point of this todo item is ability to do this without need of developer tools. Also from the thread, https://www.postgresql.org/message-id/20120821.121611.501104647612634419.t-ishii@sraoss.co.jp > +1. It would also be popular with our academic users. > There could be potential for this as well. -- Regards, Ankit Kumar Pandey
В списке pgsql-hackers по дате отправления: