Thom Brown <t...@linux.com> writes:
> Perhaps I may have misunderstood, or not explained my question with
> enough detail, but you appear to be including activity that would, in
> all likelihood, occur after the DML has returned confirmation to the
> user that it has completed; in particular, VACUUM. What I was
> thinking of was an execution plan node to communicate the index
> modifications that are carried out prior to confirmation of the query
> completing. The bgwriter, WAL writer et al. that spring into action
> as a result of the index being updated wouldn't, as I see it, be
> included.
> So in essence, I'd only be looking for a breakdown of anything that
> adds to the duration of the DML statement. However, it sounds like
> even that isn't straightforward from what you've written.
I think that would be reasonably straightforward, though perhaps too
expensive depending on the speed of clock reading. My larger point was
that I don't think that that alone is a fair measure of the cost of
maintaining an index, which is what you had claimed to be interested in.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
