On Tue, Jun 16, 2009 at 1:53 PM, Andres Freund<and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers