Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)
От | Robert Haas |
---|---|
Тема | Re: Hide 'Execution time' in EXPLAIN (COSTS OFF) |
Дата | |
Msg-id | CA+TgmoZqpJNyyxYo9h4P_wfF5c=v3WvstmDuXvQxE5G8bbef7g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hide 'Execution time' in EXPLAIN (COSTS OFF) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)
|
Список | pgsql-hackers |
On Sun, Oct 12, 2014 at 11:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Ronan Dunklau <ronan@dunklau.fr> writes: >> That wouldn't solve the first problem mentioned, which is that for some >> regression tests one may want to test the costs themselves, which is now >> impossible with the new planning time feature. > > That's a bogus argument, because it was impossible before too. We have > no such tests now, and it's unlikely we will ever add any, because costs > inherently are platform-dependent. The reason we invented COSTS OFF in > the first place was to make it possible to do EXPLAIN in regression tests > without getting platform-dependent output. > > I have no great objection to making both COSTS OFF and TIMING OFF suppress > the "planning time" output, if that's the consensus. I would object to > taking away that behavior of COSTS OFF, because of the implications for > back-patching EXPLAIN queries in regression tests. > > Another possibility, which would introduce less non-orthogonality into > the switch design, is to remove the connection to COSTS OFF but say that > planning time is only printed when execution time is also printed (ie, > only in EXPLAIN ANALYZE). This seems to me that it would not be removing > much functionality, because if you just did a plain EXPLAIN then you can > take the client-side runtime (psql \timing) as a close-enough estimate > of planning time. That'd be fine with me. Making it controlled by COSTS and/or TIMING would be OK with me, too. But let's do *something*. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: