Re: Explain discussion question

>   The question is whether in revisiting EXPLAIN we start from scratch and
> ask what people need or whether we believe that the existing EXPLAIN is
> the compilation of the requirements?  I am hearing significant drive
> towards starting over - that is gathering everyones requirements and putting
> together new records.

We use Explain. We found only a small percentage of what is in Explain
useful, and have done several new categories of our own instead to
capture the information that we require that Explain does not cover.

However, migrating to a new Explain structure is not a small effort.
It also seems a pity to throw away the bits that are OK and force
people to really support two modes of explain (new and old). For
most vendors wanting to do a good job of handling both versions.

My suggestion is to do new analysis starting from scratch.

After this, then compare back to the existing mechanism to see what
currently exists and is useful. Then introduce new explain categories
and possibly depricate old categories. The Explain database can be
made to support multiple record syntaxes, so the new categories could
all only support an XML encoding for example. In other words, I am
not saying the current explain record syntax must be extended.
I am saying that this is an orthogonal problem to the semantic contents.

I don't mean to side track the issue onto formats for Explain data
(you said you wanted to focus on content, not representation),
but this clearly needs to be addressed at some stage for the new
approach to take off. And I had not seen anyone else respond yet.

Alan Kent

ps: I would be happy to submit the extended explain categories we
have developed for private use. They are not perfect, but might be
useful as a starting point of requirements beyond what Explain
does now. Or I can knock up text describing the requirements we
are trying to achieve as distinct from the way we have implemented them.

Received on Monday, 13 November 2000 23:11:51 UTC