"Alex Hunsaker" <badalex@gmail.com> wrote:
> >> > What did you want done with this patch? It is unlikely we want to see
> >> > those counters by default, and we have had little demand for them.
> >>
> >> This was already rejected in connection with pg_stat_statements, no?
> >
> > You know, I thought we discussed it as part of that patch, but the
> > author was Vladimir Sitnikov, not the pg_stat_statement author, Alex
> > Hunsaker, so I am just checking.
>
> I assume you mean Itagaki-san not me :)
I think there two independent items here: [1] Should we add those statistics to pg_stat_statements or not? [2] Should
weadd those statistics to EXPLAIN ANALYZE or not?
I wanted to have [1] and proposed it, but it is rejected from 8.4.
However, the reason is not because we have little demand for it,
but [1] and [2] are mixed in the patch and they are bad designed.
[2] is requested by Vladimir (not me), but I think it is reasonable.
Expart users, including core members ;-), can easily find why an plan
node is slow when they have an output form EXPLAIN ANALYZE.
However, it is not true for beginners. They will be able to find
the reason if there are CPU and I/O information for each plan node.
Personally I think both of them are TODO items,
but there are some additional requirements for them.
[1] should be independent from [2] and ideally to be implemented
only in contrib modules, apart from the core.
[2] have at least two requirements: - Avoid overheads. If checking cpu usage is slow, we'd better to have only buffer
counters.- Output plans with statistics more readable way. It would be better to use XML or tables to show the
information.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center