Re: Auto-explain patch
От | Dean Rasheed |
---|---|
Тема | Re: Auto-explain patch |
Дата | |
Msg-id | BAY102-W5671BCFE39C75FD48C0C91F2910@phx.gbl обсуждение исходный текст |
Список | pgsql-hackers |
> After sleeping on this, I think we should follow your idea. > Hmm. I preferred your idea ;-) It reduces the number of new parameters back down to 3, which makes it easier to use: * trace_min_planner_duration - int, PGC_USERSET * trace_min_executor_duration - int, PGC_USERSET * trace_explain_plan - bool, PGC_USERSET (I already decided to drop the "sql_") with all output going to new level TRACE as you described. So output goes to client and not server log by default as soon as either of the first 2 parameters is enabled. I've attached what I've done so far, which works according to the above description. I've not done much testing or written any docs yet, It would be good to know if this is along the right lines. Changing parameter names is easy, although admittedly very important to get right. You didn't say why you changed your mind on this? I'm more concerned about any possible security holes it opens up. For SQL in SQL functions, it just gives the function name and statement number. For EXECUTEd queries, it doesn't have access to the SQL, so it just logs the other stuff and any context info. For plpgsql functions it will log values which appear as literals in any queries, but actually debug_print_parse exposes far more info in this case. _________________________________________________________________ 100’s of Nikon cameras to be won with Live Search http://clk.atdmt.com/UKM/go/101719808/direct/01/
Вложения
В списке pgsql-hackers по дате отправления: