db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6256) Move the XmlVTI into the product.
Date Wed, 12 Jun 2013 21:32:20 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681660#comment-13681660
] 

Mike Matrigali commented on DERBY-6256:
---------------------------------------

3) optimizerTracing - The new xml-style tracing is intended to help diagnose performance problems
in production. We don't currently document either style of optimizer tracing. If we were to
document the old-style optimizer trace, I think that all we could tell people would be to
send us the output. I think that the xml-style trace could potentially be used to guide a
customer to the selection of optimizer overrides for working around a production problem.

I don't think old-style optimizer trace is production ready.  It is not documented and not
tested as far as I know.  On the other hand it is useful.  So as you said in the past we put
this in debug code
and that made it hard for users.  I assume new style is not really production ready either,
as I have not seen much testing, and we are likely looking to improve this based on customer
feedback so
would want it to not get tied to upward compatiblity at this point.  Not sure the intent.
 

As to where to put it, I see many embedded applications are likely to not be able to use it
at all no matter what jar, without shutting down/booting.  Others might.  Again I see it as
not core, but 
instead optional for those that want to use it.  I was ok with the performance impact description
from rick on this feature.  It seemed like those not enabling the tracing did not pay code
path
price.  Would be good to eliminate code bloat default price if possible.  
                
> Move the XmlVTI into the product.
> ---------------------------------
>
>                 Key: DERBY-6256
>                 URL: https://issues.apache.org/jira/browse/DERBY-6256
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL, Tools
>    Affects Versions: 10.11.0.0
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: derby-6256-01-aa-move-XmlVTI-into-product.diff, derby-6256-02-aa-allowParentTags.diff
>
>
> The XmlVTI under derbyDemo has been useful to me for many years. It has become even more
useful now that Derby supports varargs. That is because varargs make it very easy to declare
an XmlVTI. At this point, I think it is worth re-phrasing the XmlVTI in terms of varargs and
moving it into the product so that we can use it for internal table functions. There is no
rush to expose XmlVTI as part of Derby's public api, but we could consider doing that if other
people find this table function to be useful.
> The XmlVTI is a table function which turns an xml file into a tabular data set which
you can query via sql. When you declare an XmlVTI, you state the following arguments:
> 1) The url of an xml file.
> 2) The name of the element in the xml file which you want to treat as a record or row.
> 3) The names of the attributes and subelements of that record which you want to treat
as columns. Now that we have varargs, it is possible to represent this trailing argument as
a variable length argument list.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message