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.
A tale of automating tests of Pg with Bash
Word of warning: this blogpost is about thing related to Bash (well, maybe other shells too, didn't really test), but since I found it while doing Pg work, and it might bite someone else doing Pg related work, I decided to add it to “postgresql" tag.
So, due to some work I had to do, I needed a quick, repeatable way to setup some Pg instances, replication between them, and some data loader. All very simple, no real problems. At least that's what I thought…
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.
Win a book contest – PostgreSQL Backup and Restore How-to
Around the time that Xzilla wrote about the book, Packt contacted me and asked for a review.
Since I generally don't really read technical books, I declined the offer, but Sandy from Packt was very persistent, and asked if I could inform about book giveaway contest.
The book is definitely PostgreSQL related, and Xzilla suggested to check it out, so here it goes:
Continue reading Win a book contest – PostgreSQL Backup and Restore How-to
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?
Waiting for 9.3 – Support indexing of regular-expression searches in contrib/pg_trgm.
On 9th of April, Tom Lane committed patch:
Support indexing of regular-expression searches in contrib/pg_trgm. This works by extracting trigrams from the given regular expression, in generally the same spirit as the previously-existing support for LIKE searches, though of course the details are far more complicated. Currently, only GIN indexes are supported. We might be able to make it work with GiST indexes later. The implementation includes adding API functions to backend/regex/ to provide a view of the search NFA created from a regular expression. These functions are meant to be generic enough to be supportable in a standalone version of the regex library, should that ever happen. Alexander Korotkov, reviewed by Heikki Linnakangas and Tom Lane
One day later Tom Lane added support for the same operations using GiST indexes (original patch was working only with GIN).
Waiting for 9.3 – Add \watch [SEC] command to psql.
On 4th of April, Tom Lane committed patch:
Add \watch [SEC] command to psql. This allows convenient re-execution of commands. Will Leinweber, reviewed by Peter Eisentraut, Daniel Farina, and Tom Lane
Continue reading Waiting for 9.3 – Add \watch [SEC] command to psql.