Robert Haas wrote
> On Thu, May 8, 2014 at 2:31 AM, Jaime Casanova <
> jaime@
> > wrote:
>> On Wed, May 7, 2014 at 10:52 PM, Amit Kapila <
> amit.kapila16@
> > wrote:
>>> On Thu, May 8, 2014 at 5:30 AM, Jaime Casanova <
> jaime@
> > wrote:
>>
>> QUERY PLAN
>> --------------------------------------------------------------------------------------------
>> Insert on public.t1 (actual time=0.540..0.540 rows=0 loops=1)
>> -> Result (actual time=0.046..0.049 rows=1 loops=1)
>> Output:
> <some long data here>
>> Index uniq_idx_on_text on t1: time=0.421 rows=1
>> Index t1_pkey on t1: time=0.027 rows=1
>> Total runtime: 0.643 ms
>> (6 rows)
>
> I would have expected the information about index maintenance times to
> be associated with the Insert node, not the plan overall. IIUC, you
> could have more than one such node if, for example, there are
> writeable CTEs involved.
Even with multiple nodes I would think that typically each node would focus
on a different table and so listing everything, by table, at the bottom of
the explain would not cause that much of an issue. Even if a table gets hit
from two CTEs, and thus have their calls and times added together, the
relative (per call) numbers overall and comparative numbers between indexes
on the same table would remain constant. And if you are testing indexes you
would likely want to keep the queries the same.
Not having to scan through and handle multiple locations for index timings
will make interpretation, parsing, and presentation much easier. It
wouldn't preclude having total timings and node timings in the future if the
demand is sufficient.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/WIP-showing-index-maintenance-on-EXPLAIN-tp5803106p5803337.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.