On 4th of March, Alvaro Herrera committed patch:
auto_explain: Add logging of trigger execution Author: Kyotaro HORIGUCHI Reviewed-by: Jaime Casanova
Continue reading Waiting for 9.4 – auto_explain: Add logging of trigger execution
Tag: explain
Waiting for 9.4 – Include planning time in EXPLAIN ANALYZE output.
On 29th of January, Robert Haas committed patch:
Include planning time in EXPLAIN ANALYZE output. This doesn't work for prepared queries, but it's not too easy to get the information in that case and there's some debate as to exactly what the right thing to measure is, so just do this for now. Andreas Karlsson, with slight doc changes by me.
Continue reading Waiting for 9.4 – Include planning time in EXPLAIN ANALYZE output.
Waiting for 9.4 – Improve EXPLAIN to print the grouping columns in Agg and Group nodes.
On 12th of December, Tom Lane committed patch:
Improve EXPLAIN to print the grouping columns in Agg and Group nodes. Per request from Kevin Grittner.
explain.depesz.com – update, new (great!) feature
I just updated explain.depesz.com – my tool for analysis of explain analyze plans.
New feature is: you can now create accounts.
Continue reading explain.depesz.com – update, new (great!) feature
Explaining the unexplainable – part 5
In previous posts in this series, I talked about how to read EXPLAIN output, and what each line (operation/node) means.
Now, in the final post, I will try to explain how it happens that Pg chooses “Operation X" over “Operation Y".
Explaining the unexplainable – part 4
In this, hopefully 2nd to last, post in the series, I will cover the rest of usually happening operations that you can see in your explain outputs.
Explaining the unexplainable – part 3
In previous post in the series I wrote about how to interpret single line in explain analyze output, it's structure, and later on described all basic data-getting operations (nodes in explain tree).
Today, we'll move towards more complicated operations.
Explaining the unexplainable – part 2
Last time I wrote about what explain output shows. Now I'd like to talk more about various types of “nodes" / operations that you might see in explain plans.
Explaining the unexplainable
One of the first things new DBA hears is “Use the EXPLAIN". And upon first try he/she is greeted with incomprehensible:
QUERY PLAN --------------------------------------------------------------------------------------------------------------------------- Sort (cost=146.63..148.65 rows=808 width=138) (actual time=55.009..55.012 rows=71 loops=1) Sort Key: n.nspname, p.proname, (pg_get_function_arguments(p.oid)) Sort Method: quicksort Memory: 43kB -> Hash Join (cost=1.14..107.61 rows=808 width=138) (actual time=42.495..54.854 rows=71 loops=1) Hash Cond: (p.pronamespace = n.oid) -> Seq Scan on pg_proc p (cost=0.00..89.30 rows=808 width=78) (actual time=0.052..53.465 rows=2402 loops=1) Filter: pg_function_is_visible(oid) -> Hash (cost=1.09..1.09 rows=4 width=68) (actual time=0.011..0.011 rows=4 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 1kB -> Seq Scan on pg_namespace n (cost=0.00..1.09 rows=4 width=68) (actual time=0.005..0.007 rows=4 loops=1) Filter: ((nspname <> 'pg_catalog'::name) AND (nspname <> 'information_schema'::name))
What does it even mean?
Changes on explain.depesz.com
So, I made some changes to explain.depesz.com, and while informing about it, I'd like to brag a bit about numbers, again 🙂