[Maria-developers] Fwd: [Commits] Rev 3071: Fix LP bug lp:802979 in file:///home/tsk/mprog/src/5.3-mwl89/
Sergey Could you please review my fix for bug lp:802979. I need you specifically because I needed to touch the range optimzizer to disable evaluation of single-row subqueries. Please consider if I chose the best place in the range optimizer to disable this evaluation of single-row subqueries. I will be back from vacation on Tuesday, so if there is need for discussion, we can talk on Tuesday evening or Wednesday any time. Timour -------- Original Message -------- Return-Path: <commits-bounces@mariadb.org> X-Original-To: timour@askmonty.org Delivered-To: timour@askmonty.org Received: from localhost (localhost.localdomain [127.0.0.1]) by hasky.askmonty.org (Postfix) with ESMTP id 2FB01D0A86; Mon, 4 Jul 2011 14:51:35 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at mail.askmonty.org Received: from hasky.askmonty.org ([127.0.0.1]) by localhost (mail.askmonty.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhBdpL-sj25D; Mon, 4 Jul 2011 14:51:34 +0300 (EEST) Received: from hasky.askmonty.org (localhost.localdomain [127.0.0.1]) by hasky.askmonty.org (Postfix) with ESMTP id D6837D0A72; Mon, 4 Jul 2011 14:51:34 +0300 (EEST) Received: by hasky.askmonty.org (Postfix) id 13265D0A72; Mon, 4 Jul 2011 14:51:33 +0300 (EEST) Delivered-To: commits@mariadb.org Received: from localhost (localhost.localdomain [127.0.0.1]) by hasky.askmonty.org (Postfix) with ESMTP id 02961D0A84 for <commits@mariadb.org>; Mon, 4 Jul 2011 14:51:33 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at mail.askmonty.org Received: from hasky.askmonty.org ([127.0.0.1]) by localhost (mail.askmonty.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbI1dw-8fTxt for <commits@mariadb.org>; Mon, 4 Jul 2011 14:51:29 +0300 (EEST) Received: from localhost6.localdomain6 (unknown [213.226.63.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hasky.askmonty.org (Postfix) with ESMTPSA id DC670D0A72 for <commits@mariadb.org>; Mon, 4 Jul 2011 14:51:28 +0300 (EEST) Content-Type: multipart/mixed; boundary="===============4096211003537732309==" MIME-Version: 1.0 From: <timour@askmonty.org> User-Agent: bzr/2.3.1 To: <commits@mariadb.org> Message-Id: <20110704115128.DC670D0A72@hasky.askmonty.org> Date: Mon, 4 Jul 2011 14:51:28 +0300 (EEST) Subject: [Commits] Rev 3071: Fix LP bug lp:802979 in file:///home/tsk/mprog/src/5.3-mwl89/ X-BeenThere: commits@mariadb.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: maria-developers@lists.launchpad.net List-Id: MariaDB Commits List <commits.mariadb.org> List-Unsubscribe: <https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits>, <mailto:commits-request@mariadb.org?subject=unsubscribe> List-Archive: <http://lists.askmonty.org/pipermail/commits> List-Post: <mailto:commits@mariadb.org> List-Help: <mailto:commits-request@mariadb.org?subject=help> List-Subscribe: <https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits>, <mailto:commits-request@mariadb.org?subject=subscribe> Sender: commits-bounces@mariadb.org Errors-To: commits-bounces@mariadb.org At file:///home/tsk/mprog/src/5.3-mwl89/ ------------------------------------------------------------ revno: 3071 revision-id: timour@askmonty.org-20110704115116-cx7ibyty8uiwrpg7 parent: igor@askmonty.org-20110630030724-l43c25gdezawuum3 fixes bug(s): https://launchpad.net/bugs/802979 committer: timour@askmonty.org branch nick: 5.3-mwl89 timestamp: Mon 2011-07-04 14:51:16 +0300 message: Fix LP bug lp:802979 Analysis: This bug consists of two related problems that are result of too early evaluation of single-row subqueries during the optimization phase of the outer query. Several optimizer code paths try to evaluate single-row subqueries in order to produce a constant and use that constant for further optimzation. When the execution of the subquery peforms destructive changes to the representation of the subquery, and these changes are not anticipated by the subsequent optimization phases of the outer query, we tipically get a crash or failed assert. Specifically, in this bug the inner-most suqbuery with DISTINCT triggers a substitution of the original JOIN object by a single-table JOIN object with a temp table needed to perform the DISTINCT operation (created by JOIN::make_simple_join). This substitution breaks EXPLAIN because: a) in the first example JOIN::cleanup no longer can reach the original table of the innermost subquery, and close all indexes, and b) in this second test query, EXPLAIN attempts to print the name of the internal temp table, and crashes because the temp table has no name (NULL pointer instead). Solution: a) fully disable subquery evaluation during optimization in all cases - both for constant propagation and range optimization, and b) change JOIN::join_free() to perform cleanup irrespective of EXPLAIN or not.
Could you please review ASAP, as this bug blocks RQG testing of your tree. Timour
Hi Timour, On Mon, Jul 04, 2011 at 03:40:49PM +0300, Timour Katchaounov wrote:
Sergey
Could you please review my fix for bug lp:802979. I need you specifically because I needed to touch the range optimzizer to disable evaluation of single-row subqueries.
Please consider if I chose the best place in the range optimizer to disable this evaluation of single-row subqueries.
I will be back from vacation on Tuesday, so if there is need for discussion, we can talk on Tuesday evening or Wednesday any time.
I think I have some questions about this fix. Could you catch me on irc so we could discuss it? BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog
Sergey, In our discussion we agreed that I check why in several EXPLAINs the value of the "rows" column changed from 1 to 0. The cause is casting. If range optimization is blocked for those queries, then the value of POSITION::records_read is 0.69999999999999996. This value is cast to ha_rows in the following place: get_best_combination() { .... /* Save records_read in JOIN_TAB so that select_describe()/etc don't have to access join->best_positions[]. */ j->records_read= (ha_rows)join->best_positions[tablenr].records_read; .... } The logic of select_describe for the "filtered" column is to set it to 0 if examined_rows is 0 (and it is because of the above). We get the number 0.6999... in best_access_path(), in the following line: /* quick_range couldn't use key! */ records= (double) s->records/rec; where: s->records = 7 rec = 10 Honestly, I don't know whether the above result is fine or not. If we should never get an estimate of 0 for the number of records, then we should use the proper rounding function (ceil for instance) instead of relying on casting. Alternatively, we should not use casting, but we should change the type of all the relevant variables/class members to double. In addition we should add to get_best_combination() a DEBUG_ASSERT(join->best_positions[tablenr].records_read > 0) to verify that we got a reasonable value. Let me know what you think, and whether I can push my fix. Timour
participants (2)
-
Sergey Petrunya -
Timour Katchaounov