On Tue, Jun 16, 2009 at 1:53 PM, Andres Freund<andres@anarazel.de> wrote:
> While that also looks sensible the more structured variant makes it easier
> to integrate additional stats which may not easily be pressed in the
> 'attribute' format. As a fastly contrived example you could have io
> statistics over time like:
> <iostat>
> <stat time="10" name=pagefault>...</stat>
> <stat time="20" name=pagefault>...</stat>
> <stat time="30" name=pagefault>...</stat>
> </iostat>
>
> Something like that would be harder with your variant.
Actually that's exactly the kind of example I had in mind to make easier.
I'm picturing adding a new tag, such as <iostats>, or actually I was
thinking of <dtrace>. If we have separate tags for all the estimates
and actual timings then any tags which come with the <iostat> or
<dtrace> option would just get mixed up with the estimates and timing
info.
Each new module would provide a single tag which would have some
attributes and some child tags depending on how much structure it
needs. In cases where there's no structure, just a fixed list of
scalars like the existing expected and actual stats I don't see any
advantage to making each scalar a tag. (There's not much disadvantage
except I would have said it was completely unreadable for a human
given that you would have pages and pages of output for a significant
size plan.)
So your plan might look like
<scan type=...> <expected cost=...></> <actual time=...></> <iostats> <samples> <sample time=nnn
value=nnn></> </samples> </iostats> <dtrace script="foo.d"> <probes> <probe name=foo result=nnn></>
<probe name=bar result=nnn></> </probes> </dtrace>
That would make it easy for a tool like pgadmin which doesn't know
what to do with the iostats to ignore the whole chunk, rather than
have to dig through a list of stats some of which come from iostats
and some from dtrace and some from the instrumentation and have to
figure out which tags are things it can use and which are things it
can't.
--
Gregory Stark
http://mit.edu/~gsstark/resume.pdf
