Sql on enumerator.dev

One WEIRD Trick for Speeding Up ORDER BY That You Probably Shouldn't Use

Thu, 29 Apr 2021 00:00:00 +0000

I originally posted this on dev.to, and I’m reposting it here because I often link people to it when they are trying to understand Postgres performance issues.

I was digging into a performance issue at work recently and found THE WEIRDEST way of speeding up a query that uses ORDER BY. When testing against our replica database, I was getting results up to 100 times faster than before.

“Too good to be true!” I thought. Well, it turns out that it is sort of too good to be true.

The WEIRD Trick

Here’s an example query that was having issues. We’re selecting some records and ordering by ID.

SELECT *
FROM activities
WHERE account_id IN (999102,989987,809354,100964)
ORDER BY id DESC
LIMIT 10;

In the explain plan, we’re spending almost 9 seconds scanning the index for activities.id 😯

This was baffling to me! We’re using an index, why is this slow?!

As any good developer does, I went digging in Stack Overflow for answers. Unfortunately, I can’t find the original answer I was looking at, but someone had suggested adding + 0 to the ORDER BY clause.

WHAT?! So I tried it.

EXPLAIN ANALYSE SELECT *
FROM activities
WHERE account_id IN (999102,989987,809354,100964)
ORDER BY id + 0 DESC
LIMIT 10;

Limit (cost=32383.82..32383.84 rows=8 width=149) (actual time=71.250..71.252 rows=8 loops=1)
  -> Sort (cost=32383.82..32410.22 rows=10557 width=149 (actual time=71.249..71.250 rows=8 loops=1)
    Sort Key: ((id + 0)) DESC
    Sort Method: top-N heapsort Memory: 26kB
    -> Index Scan using index_activities_on_account_user_id on activities (cost=0.57..32172.68 rows=10557 width=149) (actual time=2.292..71.154 rows=132 loops=1)
      Index Cond: (account_user_id = ANY ('{999102,989987,809354,100964}'::integer[]))
Planning Time: 0.122 ms
Execution Time: 71.279 ms

🤯 71.279 ms!!!!!

What in the ACTUAL is happening here?

Well, first, you should know that this table is pretty big. There are just under 100,000,000 records in it. AND, you should know that in some cases, this query can return LOTS of records without the LIMIT in there. In the EXPLAIN plan screen shot above, you can see that the query found just under 9,000 records, but couldn’t apply the LIMIT until they were sorted.

Another thing to know here is that this table is busy. We add almost 1,000,000 records in a day. Which means that those 9,000 records have IDs that are pretty far apart. There are big gaps between the numbers returned in the ID column.

Imagine this query returned 100 records, but the IDs were more than 100 apart. E.g., IDS 100, 200, 300…etc. When postgres is trying to sort these records it does a reverse scan through the index and has to read the order of EVERY number including the ones not returned by the query.

So what is this magic + 0 doing? Adding + 0 to the ORDER BY clause forces Postgres to load the records into memory and sort them without the index, which is way faster. You can see in the explain plan above, that the sort in memory was super fast.

Why You Probably Shouldn’t Do This in Production

This really depends on your data. I knew that only a small percentage of users were experiencing really slow requests due to this query, but I didn’t know what the impact of the + 0 magic would be on users that have fewer activities records. So I ran an experiment using GitHub’s Scientist gem.

The results of the experiment are still coming in, but so far, the original ORDER BY is almost tied with ORDER BY id + 0 for average execution time. However, the 95 percentile execution time (meaning 5% of queries are slower than this number), are way out of sync! ORDER BY id + 0 is almost twice as slow in the 95 percentile category.

The results of the experiment tell me that overall, ORDER BY with an index scan might cause timeouts for some users, but ORDER BY id + 0 with no index scan seems to cause slower queries overall for most users.

Looks like I’m going to have to find a different solution to this problem.

Conclusion

Adding + 0 to your ORDER BY id is a wacky trick that will speed up queries when the index is HUGE and the IDs returned have big intervals.

However, it won’t always work. Indexes are still fast! Test your queries safely in production to make sure that you’re not making a worse experience overall to save a few slow queries.

Concatenating MySQL Results with Group_concat and Concat_ws

Sat, 26 May 2018 12:00:00 +0000

Recently, I needed to build a query that would transform data in our database into a format that we posted to ElasticSearch. I’ll use the example of blog posts here since they’re easy for everyone to grasp. Imagine that each post can have many tags, and you want one field on ElasticSearch with the tag IDs and another field that has the tag names and descriptions.

Here’s what the database might look like:

posts

id | title
---|------------------------------
1  | Blogging about dogs is fun!
2  | Look at these cute dogs
3  | Wow how about these cute dogs

post_tags

post_id | tag_id
--------|-------
1       | 1
1       | 2
2       | 1
2       | 3
3       | 1

tags

id | name | description
---|------|-----------------
1  | dogs | Posts about dogs
2  | cute | Cute things
3  | omg  | OMG CUTE

And here is the result we’re looking for:

id | title                       | tag_ids | tag_names_descriptions
---|-----------------------------|---------|------------------------------------------
1  | Blogging about dogs is fun! | 1, 2    | dogs, cute, Posts about dogs, Cute things

Starting Query

Let’s start by retrieving a join table of our posts and tags. We’ll limit this to one post to keep our tables small for this example.

SELECT post.id,
       post.title,
       tag.id          AS tag_id,
       tag.name        AS tag_name,
       tag.description AS tag_description
FROM   posts post
       INNER JOIN posts_tags pt
               ON pt.post_id = post.id
       INNER JOIN tags tag
               ON tag.id = pt.tag_id
LIMIT  1;

id | title                       | tag_id | tag_name | tag_description
---|-----------------------------|--------|----------|-----------------
1  | Blogging about dogs is fun! | 1      | dogs     | Posts about dogs
2  | Blogging about dogs is fun! | 2      | cute     | Cute things

Ok, great, we have a table with our post and its tags, but we have duplicate rows! We can use GROUP BY to group these row by the post id, but then we’ll lose the tag data in the second row and get a result that looks like this:

id | title                       | tag_id | tag_name | tag_description
---|-----------------------------|--------|----------|-----------------
1  | Blogging about dogs is fun! | 1      | dogs     | Posts about dogs

Group_concat

We can use the Group_concat function to concatenate data from multiple rows when we use GROUP BY:

SELECT post.id,
       post.title,
       Group_concat(tag.id) AS tag_ids,
       tag.name             AS tag_name,
       tag.description      AS tag_description
FROM   posts post
       INNER JOIN posts_tags pt
               ON pt.post_id = post.id
       INNER JOIN tags tag
               ON tag.id = pt.tag_id
GROUP  BY post.id
LIMIT  1;

id | title                       | tag_ids | tag_name | tag_description
---|-----------------------------|---------|----------|-----------------
1  | Blogging about dogs is fun! | 1, 2    | dogs     | Posts about dogs

Take a look at the MySQL Docs for Group_concat you can do some cool things with it like ensure the values are unique, sort the values, and choose a custom separator.

But what about our tag_name and tag_description? Here, we need to concatenate two separate columns into one!

Concat_ws

We know that Group_concat gives us a string, so if we look under String Functions in the MySQL docs, we’ll find Concat_ws. Concat_ws lets us concatenate two or more strings with a separator between them. The separator is a comma by default, but for legibility, we want a space too, so let’s use the SEPARATOR option. Here are our steps:

Concatenate the tag name:

Group_concat(tag.name SEPARATOR ", ")

Concatenate the tag description:

Group_concat(tag.description SEPARATOR ", ")

And concatenate both of those!

Concat_ws(
  ", "
  Group_concat(tag.name SEPARATOR ", "),
  Group_concat(tag.description SEPARATOR ", ")
)

Putting it all together

SELECT post.id,
       post.title,
       Group_concat(tag.id) AS tag_ids,
       Concat_ws(
         ", "
         Group_concat(tag.name SEPARATOR ", "),
         Group_concat(tag.description SEPARATOR ", ")
       )                    AS tag_names_descriptions
FROM   posts post
       INNER JOIN posts_tags pt
               ON pt.post_id = post.id
       INNER JOIN tags tag
               ON tag.id = pt.tag_id
GROUP  BY post.id
LIMIT  1;

id | title                       | tag_ids | tag_name   | tag_descriptions
---|-----------------------------|---------|------------|------------------------------
1  | Blogging about dogs is fun! | 1, 2    | dogs, cute | Posts about dogs, Cute things

Nice work!

In this post, we’ve learned how to use Group_concat to concatenate data in a column when using GROUP BY. Group_concat lets us keep data that would otherwise disappear when we group things.

We also learned how to combine data from multiple columns by using Concat_ws together with Group_concat. With this function, we can join multiple columns and rows together into one value.