Re: generic explain options v3
От | Robert Haas |
---|---|
Тема | Re: generic explain options v3 |
Дата | |
Msg-id | 603c8f070907231123v547c11acr657f95ac968c4f94@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: generic explain options v3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: generic explain options v3
|
Список | pgsql-hackers |
On Thu, Jul 23, 2009 at 12:08 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Ugh. I took a look at this and it turns out that there are some >> tentacles. It doesn't seem very sane to actually do anything with a >> list of DefElem nodes, so we really need to parse that list and >> convert it to a more sensible format right away (this also seems >> important for proper error checking). > > Yeah, the standard approach is to convert it into a group of values > at the start of execution of the utility command. > >> The obvious solution to that is to create the ExplainState sooner, >> back up at the ExplainQuery level. If we do that, though, then >> ExplainState will need to become a public API, because >> contrib/auto_explain calls ExplainPrintPlan(). > > Well, if we add any more options to EXPLAIN then auto_explain may well > be interested in them, so I'm not sure this is bad. The alternative > is to keep adding retail parameters to the public functions. > >> And if we do that, >> then probably we should declare it in include/nodes/execnodes.h and >> make it a node type... > > No, just a struct declared in commands/explain.h. There's no reason > for it to be part of the Node system. Oh, OK. That will work. Thanks. ...Robert
В списке pgsql-hackers по дате отправления: