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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers