PostgreSQL: Query Optimization for Mere\u00a0Humans<\/h3>\nUnderstanding a PostgreSQL execution plan with practical examples<\/h4>\n![\"\"](\"https:\/\/cdn-images-1.medium.com\/max\/1024\/0*l-3On57NJoJ7maR3\")
Photo by Greg Rakozy<\/a> on\u00a0Unsplash<\/a><\/figcaption><\/figure>\nToday, users have high expectations for the programs they use. Users expect programs to have amazing features, to be fast, and to consume a reasonable amount of resources.<\/p>\n
As developers, we should thrive to give our users the best experience possible. It\u2019s pretty common that the database becomes the bottleneck, and optimizing queries and eliminating the bottlenecks is not an easy task. Unfortunately, as programs become more and more complex, and as the data become bigger, it becomes harder to write flawless SQL\u00a0queries.<\/p>\n
Today, I am going to focus on a technique to find those bottlenecks, using the Explain<\/em> clause. My goal today is to show you that finding and eliminating those bottlenecks is not rocket science. Everyone can find their bottlenecks without breaking a\u00a0sweat.<\/p>\nThe code for this article can be found on\u00a0GitHub<\/a>.<\/p>\nNote: All images, unless otherwise noted, are by the\u00a0author.<\/p>\n
Let\u2019s explain Explain\u00a0\ud83d\udcdc<\/h3>\n
Interactions with databases are done using declarative languages, where SQL is the most common one. The database decides how and what to do behind the scenes and the only glimpse it provides is the execution plan.<\/p>\n
This limitation makes implementing proper debugging tools, and profilers almost impossible in practice. So we are kind of stuck with execution plans.<\/strong><\/p>\nBuzzword alert \ud83d\udc1d!! my goal is to democratize execution plans.<\/h4>\n
In PostgreSQL in order to get the execution plan one should use Explain<\/em>\/Explain analyze\u00a0<\/em>clauses:<\/p>\n\n- \nEXPLAIN<\/em> shows what the planner planned to\u00a0do.<\/li>\n
- \nEXPLAIN ANALYZE<\/em> what the planner plans to do, execute the query,<\/strong> and also show how it did\u00a0it.<\/li>\n<\/ul>\n
Pro Tip #1<\/strong>\ud83d\udc83: go over an execution plan at least once in your career. It’s similar across databases, and it is a rare skill in companies.<\/p>\nPro Tip #2 <\/strong>\ud83d\udc83: prefer EXPLAIN ANALYZE<\/em> as it holds more information for most\u00a0cases.<\/p>\nWarning #1<\/strong> \u26a0\ufe0f don\u2019t use EXPLAIN ANALYZE <\/em>on destructive operations like DELETE\/UPDATE, EXPLAIN <\/em>will suffice and it doesn\u2019t run the\u00a0query.<\/p>\nWarning #2<\/strong> \u26a0\ufe0f don\u2019t use EXPLAIN ANALYZE <\/em>when resources are scarce like production monitoring, and when a query never finishes, EXPLAIN <\/em>will suffice and it doesn\u2019t run the\u00a0query.<\/p>\nExplain<\/em> is an awesome tool as it can imply reasons why a query was slow including:<\/p>\n\n- Missing\/Overused indices\/partitions.<\/li>\n
- Unoptimized database configurations.<\/li>\n
- Redundant Operations.<\/li>\n
- Stale statistics.<\/li>\n
- Too much\u00a0I\/O.<\/li>\n<\/ul>\n
For the more thorough people you can see the Explain<\/em> clause syntax in the next\u00a0figure:<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/820\/1%2AO55DqK52i4rQy8kWvO7REg.png?ssl=1\")
PostgreSQL Explain Clause\u00a0Syntax<\/figcaption><\/figure>\nUnderstanding Explain Anatomy\ud83e\udec0<\/h3>\n
We will use it as an example of a simple query: we want to count the number of users that don\u2019t have Twitter\u00a0handles.<\/p>\n
EXPLAIN ANALYZE
SELECT COUNT(*) FROM users WHERE twitter != '';<\/pre>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/proxy\/1%2AdfsAx-mjU3KhZSbsKR9yfg.png?ssl=1\")
We can see the execution plan returned from the EXPLAIN ANALYZE\u00a0clause<\/figcaption><\/figure>\nIt looks cryptic at first, and It\u2019s even longer than our query, and that on a small example of real-world execution plans can be overwhelming if you don’t focus\u00a0\ud83d\ude2d.<\/p>\n
But it does provide useful information. <\/strong>We can see that the query execution took 1.27 seconds, while the query planning took only 0.4 milli-seconds (negligible time).<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/proxy\/1%2AtcijQ_GFp8iq--nnxbtmAg.png?ssl=1\")
We can see the time the query planning and execution took<\/figcaption><\/figure>\nThe execution plan is structured as an inverse tree. In the next figure, you can see the execution plan is divided into different nodes each one of which represents a different operation whether it’s an Aggregation<\/em> or a\u00a0Scan.<\/em><\/p>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/proxy\/1%2APOmK5sHID4H5APlfbmaL-w.png?ssl=1\")
We can see the time the query planning and execution took<\/figcaption><\/figure>\nThere are many kinds of nodes operations, from Scan related (\u2018Seq Scan\u2019, \u2018Index Only Scan\u2019, etc\u2026<\/em>), Join related( \u2018Hash Join\u2019, \u2019Nested Loop\u2019, etc\u2026), <\/em>Aggregation related (\u2018GroupAggregate\u2019, \u2019Aggregate\u2019, etc\u2026) <\/em>and others ( \u2018Limit\u2019, \u2018Sort\u2019, \u2018materialize\u2019, etc..). <\/em>Fortunately you need to remember any of\u00a0this.<\/strong><\/p>\nPro Tip #3 <\/strong>\ud83d\udc83: Focus is key, look only on nodes that are problematic.<\/p>\nPro Tip #4 <\/strong>\ud83d\udc83: Cheat\u00a0! on the problematic nodes search what they mean in the explain glossary<\/a>.<\/p>\nNow, let’s drill down into how we know which node is the problematic one.<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/proxy\/1%2AjXnnH_uAybaahQ1WzsXdRw.png?ssl=1\")
There is a lot of information we can see on each\u00a0node<\/figcaption><\/figure>\nLet’s drill down to what those metrics actually\u00a0mean.<\/p>\n
\n- \nActual Loops<\/strong>: the number of loops the same node executed is 1. To get the total time and rows, the actual time and rows need to be multiplied by loops\u00a0values.<\/li>\n
- \nActual Rows<\/strong>: the actual number of produced rows of the Aggregate<\/em> node is 1 (per-loop average and we have loops is\u00a01).<\/li>\n
- \nPlan Rows<\/strong>: the estimated number of produced rows of the Aggregate<\/em> node is 1. The estimated number of rows can be off depending on statistics.<\/li>\n
- \nActual Startup Time<\/strong>: the time it took to return the first row in milliseconds of the Aggregate<\/em> node is 1271.157 (aggregated and includes previous operations).<\/li>\n
- \nStartup Cost<\/strong>: arbitrary units that represent the estimated time to return the first row of the Aggregate<\/em> node is 845110(aggregated and includes previous operations).<\/li>\n
- \nActual Total Time<\/strong>: the time it took to return all the rows in ms of the Aggregate<\/em> node is 1271.158 (per-loop average and we have loops is 1 and aggregated and include previous operations).<\/li>\n
- \nTotal Cost<\/strong>: arbitrary units that represent the estimated time to return all the rows of Aggregate<\/em> node is 845110 (aggregated).<\/li>\n
- \nPlan Width<\/strong>: the estimated average size of rows of the Aggregate<\/em> node is 8\u00a0bytes.<\/li>\n<\/ul>\n
Pro Tip #5 <\/strong>\ud83d\udc83: be wary of loops, remember to multiply loops when you care about Actual Rows <\/em>and Actual Total\u00a0Time.<\/em><\/p>\nWe will drill in the next section on a practical example.<\/p>\n
Example: Performance Optimization\ud83d\udc06<\/h3>\n
We will use the same query as\u00a0before.<\/p>\n
EXPLAIN ANALYZE
SELECT COUNT(*) FROM users WHERE twitter != '';<\/pre>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/proxy\/1%2AsWHKqRRwZ3zCr6M3vZFK7Q.png?ssl=1\")
We will focus on the Seq Scan node which has the longest actual\u00a0time<\/figcaption><\/figure>\nWe focus on the longest operation which is the sequential scan<\/a> on the users’ table. The scan filters out 2,487,813 rows and takes us 1.27 seconds out of\u00a01.271.<\/p>\nBut we are mere humans that don\u2019t tell us anything. <\/strong>Let’s google it (you can use ChatGPT as well)\u00a0!!!.<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/proxy\/1%2AjMQGhTdhk76sSVyrHOZBhQ.png?ssl=1\")
Googling how to make seq scan faster in PostgreSQL<\/figcaption><\/figure>\nCREATE INDEX twitter_test ON users (twitter)<\/pre>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/proxy\/1%2ABwvC6JwEIGIVnJRf9j3c_Q.png?ssl=1\")
We are doing much better, but the Scan node is still the longest in terms of actual\u00a0time<\/figcaption><\/figure>\nWe can see that now we perform an index only scan<\/a> on the users’ table. It takes us 0.29 seconds instead of 1.27 seconds, which is awesome but not enough for\u00a0us.<\/p>\nPro Tip #6<\/strong>\ud83d\udc83: optimize your queries one baby step at a\u00a0time.<\/p>\nTo understand how much data is passed to the scan. We could use the buffers parameter as you can see down\u00a0below.<\/p>\n
Pro Tip #7<\/strong>\ud83d\udc83: When comparing execution plans, look at several\u00a0metrics.<\/p>\nEXPLAIN (ANALYZE, BUFFERS)
SELECT COUNT(*) FROM users WHERE twitter != ''<\/pre>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/proxy\/1%2AZYn0VC5d7Gc8oX0w3dPAMw.png?ssl=1\")
We can see quite a lot of information about how much data hit the cache or\u00a0disk<\/figcaption><\/figure>\nWe have 51,854 pages to read all from the cache (400 MB), so improving configurations probably won\u2019t change things drastically.<\/p>\n
But, we are not out of options. Since the scan filters out 2,487,813 rows, we can change the index into a partial index but it doesn\u2019t come for free. It will cause writes to take longer, and it will take additional storage, which is quite impactful on systems that scale vertically.<\/p>\n
Pro Tip #8 <\/strong>\ud83d\udc83: there is no free\u00a0lunch.<\/p>\nGood optimization options\ud83e\udd1e\ud83c\udffb<\/h3>\n
I won\u2019t delve into too many details as this blog is already quite long. These are the first things one might want to tackle when he has slow\u00a0queries:<\/p>\n
\n- Picking the right scan\u00a0method.<\/li>\n
- Picking the right join\u00a0method.<\/li>\n
- Picking the right join\u00a0order.<\/li>\n
- Push Filters as soon as possible.<\/li>\n
- Reducing disk IO operations when\u00a0needed.<\/li>\n<\/ul>\n
In order to manually check specific optimization one can enable\/disable settings.<\/p>\n
SET enable_seqscan TO off;
EXPLAIN (ANALYZE) SELECT * FROM foo WHERE c1 > 500;
SET enable_seqscan TO on;<\/pre>\nWarning #3<\/strong> \u26a0\ufe0f: enable\/disable settings only after you tried the most basic optimizations as most of the time, PostgreSQL knows what it is\u00a0doing.<\/p>\nAren\u2019t there easier\u00a0ways?!\ud83d\ude4f<\/h3>\n
Unfortunately, Explain <\/em>is not perfect and there are reasons why it\u2019s not in every developer toolbox:<\/p>\n\n- You don\u2019t have a history of all the execution plans in production.<\/li>\n
- Not trivial to tune complex queries
\u200a\u2014\u200aIt\u2019s long, and not that easy to read.
\u200a\u2014\u200aIt doesn\u2019t tell you why a particular optimization is not used.
\u200a\u2014\u200aIt doesn\u2019t tell you how to rewrite your\u00a0queries.<\/li>\n<\/ul>\nWe can overcome the lack of history by using tools like auto_explain<\/a> and pg_stat_plans<\/a> to record the execution plans on certain conditions such that they won\u2019t have a major effect on production. Another way is to record what queries run at what time and try to reproduce it, but it’s more complicated than it\u00a0looks.<\/p>\nWe can overcome complex tuning with some very opinionated tools. These focus your attention on what works for most use cases. Some of the most prominent tools\u00a0are:<\/p>\n
\n- \neversql<\/a>\u200a\u2014\u200aa mature solution that aims to suggest changes to your PostgreSQL <\/em>queries.<\/li>\n
- \nmetis<\/a>\u200a\u2014\u200aaims to suggest changes as a guarding mechanism as part of your development and CI\/CD processes for PostgreSQL<\/em> databases.<\/li>\n
- \nQueryFlow<\/a>\u200a\u2014\u200aan open-source tool that allows identifying bugs and performance tuning multiple queries (as the hardest queries to debug behave nicely in isolation).<\/li>\n<\/ul>\n
Pro Tip #9 <\/strong>\ud83d\udc83: use tools to make your life\u00a0easy.<\/p>\nI will give you a taste of how convenient it is to use tools like QueryFlow (For more details you can read the following).<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AiVwp45epASb6E79l1ugdzw.png?ssl=1\")
QueryFlow visualization of execution plan focusing on\u00a0duration<\/figcaption><\/figure>\nIt should be extremely easy to see that the Index Only Scan <\/em>width is much bigger than the aggregation and indicate this is where we should focus. On multiple complex queries, other tools tend to\u00a0lack<\/p>\nLast words<\/h3>\n
In this article, we reviewed some of the most common reasons that can cause otherwise perfectly good SQL to be too slow for any time-sensitive applications, and walk through a mythological way to identify those and avoid\u00a0them<\/strong>.<\/p>\nDue to the extent of the topic, there are many optimizations I haven\u2019t covered. For this reason, I have added additional resources in the end if you want to go the extra\u00a0mile.<\/p>\n
I am optimistic about the future. I believe these kinds of tools will be as easy as opening files in python<\/em><\/a>, either by integrating into IDEs, and clients, or providing SAS solutions. This will enable us to become proactive instead of reactive.<\/p>\nI hope I was able to share my enthusiasm for this fascinating topic and that you find it useful, and as always I am open to any kind of constructive feedback.<\/p>\n
Additional Resources \ud83d\udcda<\/h3>\n\n- Deeper Understanding of PostgreSQL Execution Plan\u00a0(video)<\/a><\/li>\n
- EXPLAIN Explained (video)<\/a><\/li>\n
- Understanding Explain<\/a><\/li>\n<\/ul>\n
![\"\"](\"https:\/\/medium.com\/_\/stat?event=post.clientViewed&referrerSource=full_rss&postId=875ab864390a\")
<\/p>\n
\nQuery Optimization for Mere Humans in PostgreSQL<\/a> was originally published in Towards Data Science<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>\n<\/div>\n
Today, users have high expectations for the programs they use. Users expect programs to have amazing features, to be fast, and to consume a reasonable amount of resources.<\/p>\n
As developers, we should thrive to give our users the best experience possible. It\u2019s pretty common that the database becomes the bottleneck, and optimizing queries and eliminating the bottlenecks is not an easy task. Unfortunately, as programs become more and more complex, and as the data become bigger, it becomes harder to write flawless SQL\u00a0queries.<\/p>\n
Today, I am going to focus on a technique to find those bottlenecks, using the Explain<\/em> clause. My goal today is to show you that finding and eliminating those bottlenecks is not rocket science. Everyone can find their bottlenecks without breaking a\u00a0sweat.<\/p>\n The code for this article can be found on\u00a0GitHub<\/a>.<\/p>\n Note: All images, unless otherwise noted, are by the\u00a0author.<\/p>\n Interactions with databases are done using declarative languages, where SQL is the most common one. The database decides how and what to do behind the scenes and the only glimpse it provides is the execution plan.<\/p>\n This limitation makes implementing proper debugging tools, and profilers almost impossible in practice. So we are kind of stuck with execution plans.<\/strong><\/p>\n In PostgreSQL in order to get the execution plan one should use Explain<\/em>\/Explain analyze\u00a0<\/em>clauses:<\/p>\n Pro Tip #1<\/strong>\ud83d\udc83: go over an execution plan at least once in your career. It’s similar across databases, and it is a rare skill in companies.<\/p>\n Pro Tip #2 <\/strong>\ud83d\udc83: prefer EXPLAIN ANALYZE<\/em> as it holds more information for most\u00a0cases.<\/p>\n Warning #1<\/strong> \u26a0\ufe0f don\u2019t use EXPLAIN ANALYZE <\/em>on destructive operations like DELETE\/UPDATE, EXPLAIN <\/em>will suffice and it doesn\u2019t run the\u00a0query.<\/p>\n Warning #2<\/strong> \u26a0\ufe0f don\u2019t use EXPLAIN ANALYZE <\/em>when resources are scarce like production monitoring, and when a query never finishes, EXPLAIN <\/em>will suffice and it doesn\u2019t run the\u00a0query.<\/p>\n Explain<\/em> is an awesome tool as it can imply reasons why a query was slow including:<\/p>\n For the more thorough people you can see the Explain<\/em> clause syntax in the next\u00a0figure:<\/p>\n We will use it as an example of a simple query: we want to count the number of users that don\u2019t have Twitter\u00a0handles.<\/p>\n It looks cryptic at first, and It\u2019s even longer than our query, and that on a small example of real-world execution plans can be overwhelming if you don’t focus\u00a0\ud83d\ude2d.<\/p>\n But it does provide useful information. <\/strong>We can see that the query execution took 1.27 seconds, while the query planning took only 0.4 milli-seconds (negligible time).<\/p>\n The execution plan is structured as an inverse tree. In the next figure, you can see the execution plan is divided into different nodes each one of which represents a different operation whether it’s an Aggregation<\/em> or a\u00a0Scan.<\/em><\/p>\n There are many kinds of nodes operations, from Scan related (\u2018Seq Scan\u2019, \u2018Index Only Scan\u2019, etc\u2026<\/em>), Join related( \u2018Hash Join\u2019, \u2019Nested Loop\u2019, etc\u2026), <\/em>Aggregation related (\u2018GroupAggregate\u2019, \u2019Aggregate\u2019, etc\u2026) <\/em>and others ( \u2018Limit\u2019, \u2018Sort\u2019, \u2018materialize\u2019, etc..). <\/em>Fortunately you need to remember any of\u00a0this.<\/strong><\/p>\n Pro Tip #3 <\/strong>\ud83d\udc83: Focus is key, look only on nodes that are problematic.<\/p>\n Pro Tip #4 <\/strong>\ud83d\udc83: Cheat\u00a0! on the problematic nodes search what they mean in the explain glossary<\/a>.<\/p>\n Now, let’s drill down into how we know which node is the problematic one.<\/p>\n Let’s drill down to what those metrics actually\u00a0mean.<\/p>\n Pro Tip #5 <\/strong>\ud83d\udc83: be wary of loops, remember to multiply loops when you care about Actual Rows <\/em>and Actual Total\u00a0Time.<\/em><\/p>\n We will drill in the next section on a practical example.<\/p>\n We will use the same query as\u00a0before.<\/p>\n We focus on the longest operation which is the sequential scan<\/a> on the users’ table. The scan filters out 2,487,813 rows and takes us 1.27 seconds out of\u00a01.271.<\/p>\n But we are mere humans that don\u2019t tell us anything. <\/strong>Let’s google it (you can use ChatGPT as well)\u00a0!!!.<\/p>\n We can see that now we perform an index only scan<\/a> on the users’ table. It takes us 0.29 seconds instead of 1.27 seconds, which is awesome but not enough for\u00a0us.<\/p>\n Pro Tip #6<\/strong>\ud83d\udc83: optimize your queries one baby step at a\u00a0time.<\/p>\n To understand how much data is passed to the scan. We could use the buffers parameter as you can see down\u00a0below.<\/p>\n Pro Tip #7<\/strong>\ud83d\udc83: When comparing execution plans, look at several\u00a0metrics.<\/p>\n We have 51,854 pages to read all from the cache (400 MB), so improving configurations probably won\u2019t change things drastically.<\/p>\n But, we are not out of options. Since the scan filters out 2,487,813 rows, we can change the index into a partial index but it doesn\u2019t come for free. It will cause writes to take longer, and it will take additional storage, which is quite impactful on systems that scale vertically.<\/p>\n Pro Tip #8 <\/strong>\ud83d\udc83: there is no free\u00a0lunch.<\/p>\n I won\u2019t delve into too many details as this blog is already quite long. These are the first things one might want to tackle when he has slow\u00a0queries:<\/p>\n In order to manually check specific optimization one can enable\/disable settings.<\/p>\n Warning #3<\/strong> \u26a0\ufe0f: enable\/disable settings only after you tried the most basic optimizations as most of the time, PostgreSQL knows what it is\u00a0doing.<\/p>\n Unfortunately, Explain <\/em>is not perfect and there are reasons why it\u2019s not in every developer toolbox:<\/p>\n We can overcome the lack of history by using tools like auto_explain<\/a> and pg_stat_plans<\/a> to record the execution plans on certain conditions such that they won\u2019t have a major effect on production. Another way is to record what queries run at what time and try to reproduce it, but it’s more complicated than it\u00a0looks.<\/p>\n We can overcome complex tuning with some very opinionated tools. These focus your attention on what works for most use cases. Some of the most prominent tools\u00a0are:<\/p>\n Pro Tip #9 <\/strong>\ud83d\udc83: use tools to make your life\u00a0easy.<\/p>\n I will give you a taste of how convenient it is to use tools like QueryFlow (For more details you can read the following).<\/p>\n It should be extremely easy to see that the Index Only Scan <\/em>width is much bigger than the aggregation and indicate this is where we should focus. On multiple complex queries, other tools tend to\u00a0lack<\/p>\n In this article, we reviewed some of the most common reasons that can cause otherwise perfectly good SQL to be too slow for any time-sensitive applications, and walk through a mythological way to identify those and avoid\u00a0them<\/strong>.<\/p>\n Due to the extent of the topic, there are many optimizations I haven\u2019t covered. For this reason, I have added additional resources in the end if you want to go the extra\u00a0mile.<\/p>\n I am optimistic about the future. I believe these kinds of tools will be as easy as opening files in python<\/em><\/a>, either by integrating into IDEs, and clients, or providing SAS solutions. This will enable us to become proactive instead of reactive.<\/p>\n I hope I was able to share my enthusiasm for this fascinating topic and that you find it useful, and as always I am open to any kind of constructive feedback.<\/p>\n Query Optimization for Mere Humans in PostgreSQL<\/a> was originally published in Towards Data Science<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>\n<\/div>\nLet\u2019s explain Explain\u00a0\ud83d\udcdc<\/h3>\n
Buzzword alert \ud83d\udc1d!! my goal is to democratize execution plans.<\/h4>\n
\n
\n
Understanding Explain Anatomy\ud83e\udec0<\/h3>\n
EXPLAIN ANALYZE
SELECT COUNT(*) FROM users WHERE twitter != '';<\/pre>\n\n
Example: Performance Optimization\ud83d\udc06<\/h3>\n
EXPLAIN ANALYZE
SELECT COUNT(*) FROM users WHERE twitter != '';<\/pre>\nCREATE INDEX twitter_test ON users (twitter)<\/pre>\n
EXPLAIN (ANALYZE, BUFFERS)
SELECT COUNT(*) FROM users WHERE twitter != ''<\/pre>\nGood optimization options\ud83e\udd1e\ud83c\udffb<\/h3>\n
\n
SET enable_seqscan TO off;
EXPLAIN (ANALYZE) SELECT * FROM foo WHERE c1 > 500;
SET enable_seqscan TO on;<\/pre>\nAren\u2019t there easier\u00a0ways?!\ud83d\ude4f<\/h3>\n
\n
\u200a\u2014\u200aIt\u2019s long, and not that easy to read.
\u200a\u2014\u200aIt doesn\u2019t tell you why a particular optimization is not used.
\u200a\u2014\u200aIt doesn\u2019t tell you how to rewrite your\u00a0queries.<\/li>\n<\/ul>\n\n
Last words<\/h3>\n
Additional Resources \ud83d\udcda<\/h3>\n
\n
<\/p>\n
\n