Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A7C6A1751E for ; Wed, 11 Feb 2015 15:39:12 +0000 (UTC) Received: (qmail 1003 invoked by uid 500); 11 Feb 2015 15:39:12 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 972 invoked by uid 500); 11 Feb 2015 15:39:12 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 961 invoked by uid 99); 11 Feb 2015 15:39:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Feb 2015 15:39:12 +0000 Date: Wed, 11 Feb 2015 15:39:12 +0000 (UTC) From: "Stephan van Loendersloot (JIRA)" To: derby-dev@db.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (DERBY-6794) SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS(1) returns a long varchar (32,700) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Stephan van Loendersloot created DERBY-6794: ----------------------------------------------- Summary: SYSCS_UTIL.SYSCS_SET_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_SET_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/%3C48F4483B.6040906@Sun.com%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)