[
https://issues.apache.org/jira/browse/DERBY-6794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14316915#comment-14316915
]
Mike Matrigali commented on DERBY-6794:
---------------------------------------
It might be safest to propose a new get runtime statistics function that
returns a clob rather than varchar.
I agree that changing the data type of the existing function would raise
unknown compatibility issues for
existing applications. And in keeping with derby methodology even if it was
decided that it was preferred
in a new release one should support the old interface for soft upgrade and new
interface in hard upgrade.
Thus I think adding a new function might be best.
Note that there may be other issues encountered other than simply changing the
datatype as there are different
behaviors between clob and long varchar. Also memory handling implementation
may want to be different for
something "known" to be only 32k and something that could be 2gig. To get a
better understanding of scope
as a first step in my own private path I would do as you suggest and change the
datatype returned and run the
full tests and see if anything pops up. This does not prove it works, but a
good first step.
In either case such a change should only be implemented in a new release and
not back ported to previous releases.
> SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS(1) returns a long varchar (32,700)
> -------------------------------------------------------------------------
>
> Key: DERBY-6794
> URL: https://issues.apache.org/jira/browse/DERBY-6794
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Stephan van Loendersloot
> Priority: Minor
>
> The internal function SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS(1) returns a
> VARCHAR(32,700), also known as a LONG VARCHAR in Derby.
> In a lot of cases, this is not enough.
> A couple of years ago at our company, we tried to mimic EXPLAIN functionality
> as sent by MySQL, however, because MySQL didn't satisfy our needs, we needed
> a change, and needed somethings similar, as reflected here
> http://mail-archives.apache.org/mod_mbox/db-derby-user/200810.mbox/%[email protected]%3E.
> Now, we're building something like http://explain.depesz.com.
> As an example, which consists of some ridiculously simple JSP; Not by any
> means complete, but working processing engine for the explain plan, we
> created this: http://www.republika.nl/upload/explain_test.jpg
> Soon, we'll provide a link to use this for all of you, like depesz.com does.
> We'll enter some other JIRA issues to be sure about what we're doing, but
> basically it means you can simply copy & paste your explain plans.
> We do intend to give it back to the community, by releasing it via the Apache
> License v2.0, but only when we're sure that every assumption we made is
> correct. In the meantime we'll provide a URL where you can copy and paste
> explained plans, just like depesz.com does.
> However, we've got some complicated queries, for which the runtime statistics
> retrieved by the built-in function are bigger than a LONG VARCHAR...
> Is there something we can do about that?
> I've thought about changing code and making it a CLOB, but that would break
> backwards compatibility.
> I'll give a full URL within 2 weeks, so you can try and test if you like what
> you see.
> In the meantime... the issue is that we don't always get the full result
> plan, because of character limitations...
> Thanks for your attention.
> -- Stephan van Loendersloot.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
