Comments on: Optimizing repeated subexpressions in MySQL

By: Sergei Golubchik

Sergei Golubchik — Sun, 25 Jan 2009 20:23:22 +0000

To recognize common subexpressions ? No, I don’t know.

By: peter

peter — Sun, 25 Jan 2009 19:18:08 +0000

Sergei,

Do you know if this is on the roadmap to be fixed natively by the way ?

By: Lukas

Lukas — Sun, 25 Jan 2009 14:26:05 +0000

@Sergei: thats exactly the approach I meant in my original approach.

@Ms. Anthrope: right .. then again in some cases its nicer for the eyes to still do this subquery if the expression is very long.

By: Ms. Anthrope

Ms. Anthrope — Sun, 25 Jan 2009 11:11:31 +0000

Notably, Postgres does not have this particular deficiency. I often run into optimizer deficiencies in MySQL with my clients (this being one of the more minor sorts) and find myself longing for my younger days with the PGSQL.

By: Sergei Golubchik

Sergei Golubchik — Sun, 25 Jan 2009 10:21:19 +0000

You don’t need a user variable in your solution:

SELECT
pow(sum, 1),
pow(sum, 2),
pow(sum, 3),
pow(sum, 4),
pow(sum, 5),
pow(sum, 6),
pow(sum, 7),
pow(sum, 8),
pow(sum, 10),
pow(sum, 11),
pow(sum, 12),
pow(sum, 13),
pow(sum, 14),
pow(sum, 15),
pow(sum, 16),
pow(sum, 17),
pow(sum, 18)
FROM (SELECT sum(rental_id) as sum FROM sakila.rental) a

you can even write ”

…
SELECT sum(rental_id) as sum FROM sakila.rental GROUP BY customer_id
…

which isn’t possible with user variables.

By: Shlomi Noach

Shlomi Noach — Sun, 25 Jan 2009 06:10:00 +0000

Hi,

To solve the issue of whether @sum is calculated first, the query can be rewritten as:
SELECT sql_no_cache
pow(@sum, 1),
pow(@sum, 2),
pow(@sum, 3),
pow(@sum, 4),
pow(@sum, 5),
pow(@sum, 6),
pow(@sum, 7),
pow(@sum, 8),
pow(@sum, 10),
pow(@sum, 11),
pow(@sum, 12),
pow(@sum, 13),
pow(@sum, 14),
pow(@sum, 15),
pow(@sum, 16),
pow(@sum, 17),
pow(@sum, 18)
FROM
(SELECT @sum := (SELECT sum(rental_id) FROM sakila.rental)) a

In this query @sum is guaranteed to be calculated before all the pow(…) take place.

By: Sergei Golubchik

Sergei Golubchik — Sat, 24 Jan 2009 11:40:32 +0000

sorry, bad timing we were commenting at the same time, apparently, at least, your comment wasn’t here when I was writing mine.

I mean that Baron’s workaround relies on the order in which SELECT expressions are evaluated. And this order is undefined, afaik.

By: Baron Schwartz

Baron Schwartz — Sat, 24 Jan 2009 11:33:37 +0000

Sergei, indeed: in cases where it matters, such as in mk-table-checksum, I run test queries to find out which place the “real” expression needs to go and where the user variables can be substituted. The result is often that the real expression goes LAST, not first! It looks odd but it’s true — you end up using @variable apparently before it’s assigned to. In this case it needed to be first.

By: Lukas

Lukas — Sat, 24 Jan 2009 10:22:25 +0000

@Sergei: So the subquery solution is safer?

By: Sergei Golubchik

Sergei Golubchik — Sat, 24 Jan 2009 10:20:10 +0000

Just to say that your workaround isn’t guaranteed to work. The server is not required to evaluate expressions in the SELECT clause in the order they are listed. The fact that it does is an implementation detail that may change any time.