Re: WIP: explain analyze with 'rows' but not timing
От | Robert Haas |
---|---|
Тема | Re: WIP: explain analyze with 'rows' but not timing |
Дата | |
Msg-id | CA+TgmoYxJRza1uR6dC8+Fp3idPQ-9fnP__LuEp6juf=go-G0FA@mail.gmail.com обсуждение исходный текст |
Ответ на | WIP: explain analyze with 'rows' but not timing (Tomas Vondra <tv@fuzzy.cz>) |
Ответы |
Re: WIP: explain analyze with 'rows' but not timing
|
Список | pgsql-hackers |
2011/12/22 Tomas Vondra <tv@fuzzy.cz>: > The gettimeofday() calls are not exactly cheap in some cases, so why to > pay that price when all you need is the number of rows? Fair point. > The patch attached does this: > > 1) adds INSTRUMENT_ROWS, a new InstrumentOption > > - counts rows without timing (no gettimeofday() callse) > - if you want timing info, use INSTRUMENT_TIMER > > 2) adds new option "TIMING" to EXPLAIN, i.e. > > EXPLAIN (ANALYZE ON, TIMING ON) SELECT ... > > 3) adds auto_explain.log_rows_only (false by default) > > - if you set this to 'true', then the instrumentation will just > count rows, without calling gettimeofday() This seems like an unnecessarily confusing interface, because you've named the auto_explain option differently from the EXPLAIN option and given it (almost) the opposite sense: timing=off means the same thing as log_rows_only=on. I think the EXPLAIN (TIMING) option is good the way you have it, but then just have auto_explain.log_timing, with a default value of on. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: