Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 11387 invoked from network); 1 Dec 2008 19:36:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Dec 2008 19:36:05 -0000 Received: (qmail 15213 invoked by uid 500); 1 Dec 2008 19:36:16 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 15181 invoked by uid 500); 1 Dec 2008 19:36:16 -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 15170 invoked by uid 99); 1 Dec 2008 19:36:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 11:36:16 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 19:34:57 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 6C1AF234C2A2 for ; Mon, 1 Dec 2008 11:35:44 -0800 (PST) Message-ID: <766534375.1228160144441.JavaMail.jira@brutus> Date: Mon, 1 Dec 2008 11:35:44 -0800 (PST) From: "Mamta A. Satoor (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-3788) Provide a zero-admin way of updating the statisitcs of an index In-Reply-To: <1231890337.1216665811829.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652114#action_12652114 ] Mamta A. Satoor commented on DERBY-3788: ---------------------------------------- My understanding of DERBY-3892 is as follows 1)A query is exectued and the best plan for it is picked up based on the current data in the database 2)The data changes quite a bit which makes the plan chosen for the query not an optimal plan but during the next execution of the query, we continue to use the plan chosen in step 1). Based on the above understanding of DERBY-3892, the current work going on for DERBY-3788 is not going to fix DERBY-3892. This jira entry will go and build the statistics if during the query compilation it is found that the required statistics do not exist. Hope this answers your question about DERBY-3892, Dag. > Provide a zero-admin way of updating the statisitcs of an index > --------------------------------------------------------------- > > Key: DERBY-3788 > URL: https://issues.apache.org/jira/browse/DERBY-3788 > Project: Derby > Issue Type: New Feature > Components: Performance > Affects Versions: 10.5.0.0 > Reporter: Mamta A. Satoor > Assignee: Mamta A. Satoor > Attachments: DERBY3788_patch1_diff.txt, DERBY3788_patch1_stat.txt, DERBY3788_patch2_diff.txt, DERBY3788_patch2_stat.txt, DERBY_3788_Mgr.java, DERBY_3788_Repro.java > > > DERBY-269 provided a manual way of updating the statistics using the new system stored procedure SYSCS_UTIL.SYSCS_UPDATE_STATISTICS. It will be good for Derby to provide an automatic way of updating the statistics without requiring to run the stored procedure manually. There was some discussion on DERBY-269 about providing the 0-admin way. I have copied it here for reference. > ********************* > Kathey Marsden - 22/May/05 03:53 PM > Some sort of zero admin solution for updating statistics would be prefferable to the manual 'update statistics' > ********************* > ********************* > Mike Matrigali - 11/Jun/08 12:37 PM > I have not seen any other suggestions, how about the following zero admin solution? It is not perfect - suggestions welcome. > Along with the statistics storing, save how many rows were in the table when exact statistics were calculated. This number is 0 if none have been calculated because index creation happened on an empty table. At query compile time when we look up statistics we automatically recalculate the statistics at certain threshholds - say something like row count growing past next threshhold : 10, 100, 1000, 100000 - with upper limit being somewhere around how many rows we can process in some small amount of time - like 1 second on a modern laptop. If we are worried about response time, maybe we background queue the stat gathering rather than waiting with maybe some quick load if no stat has ever been gathered. The background gathering could be optimized to not interfere with locks by using read uncommitted. > I think it would be useful to also have the manual call just to make it easy to support customers and debug issues in the field. There is proably always some dynamic data distribution change that in some case won't be picked up by the automatic algorithm. Also just very useful for those who have complete control of the create ddl, load data, run stats, deliver application process. > ********************* -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.