Ühel kenal päeval, K, 2006-04-12 kell 14:38, kirjutas Jim C. Nasby:
> Well, really just about anything you'd want to do with it in an XML
> format. The advantage of SQL is that you can do it within the database,
> and you don't have to worry about having something around that can
> process XML.
>
> Some possibilities...
>
> Having an SQL format would make it easier to allow for a mode that
> captures explain or explain analyze output from every query. Turn that
> mode on, run an application's test suite, and now you have a pretty good
> idea of how all the queries will run.
Maybe. Depending on how much preprocessing is done before saving, this
can be true.
Just storing something in "SQL format" (whatever that is) doesn't not
magically make it easy to process. And storing an XML string is no more
complicated than storing a set of records.
> Or, take a production system and
> turn that option on for a single connection. Another option is to have
> any queries that take more than X amount of time store an EXPLAIN of the
> query.
OTOH, on a production system, where performance matters, you probably
still would prefer a format where collecting data is fast, and storing 1
row per plan will always be faster than storing many, especially with
indexes.
> Having this info in machine format would make it easier to write
> something that sets the various cost estimator values (random_page_cost,
> etc).
I guess that this needs to be written in C anyhow, and parsing a defined
subset of XML is not that hard.
> The list goes on. Like I said, you could do all these things with XML,
> you just couldn't easily do them within the database.
I'm not sure about it, at least without a specific example. Processing
tree-structured data is not a thing that SQL is very good at.
-------------
Hannu
