Postgres has a handy module called auto_explain. The auto_explain module lives up to its name: it runs EXPLAIN automatically for you. The intent for this module is to automatically provide information useful for troubleshooting about your slow queries as they happen. This post outlines a pitfall I recently discovered with auto_explain. Luckily for us, it's an easy thing to avoid.

I discovered this by running CREATE EXTENSION postgis; and watching it run for quite a while before failing with an out of disk space error. That is not my typical experience with a simple CREATE EXTENSION command!

Standard use of auto_explain

A common way auto_explain is used is to target "slow queries" through the setting auto_explain.log_min_duration. This setting defines the number of milliseconds to use as the threshold of when to log the EXPLAIN output. If your queries are typically 10-50 ms, you might decide to set auto_explain.log_min_duration = 100 to log queries taking twice as long as your goal. An instance serving big analytic queries might want to set that much higher, say 2 or 5 seconds.

Innocent testing

I say my testing was innocent because I wasn't trying to break something. That makes it innocent, right? I was playing around with auto_explain trying out PgMustard's scoring API. At the time I didn't want to think about where to set that threshold... I just wanted to capture some explain output for testing. The auto_explain documentation explains that setting auto_explain.log_min_duration = 0 will capture "all plans." Sounds good, let's do that!

Continue Reading

This blog post is for PGSQL Phriday #003. Read Ryan Booz' introduction from September for more details on PGSQL Phriday. Pat Wright (SQL Asylum) is this month's host and chose the topic: What is the PostgreSQL community to you?

TLDR;

The Postgres community is helpful.

One big community with many layers

The remainder of this post explores why I say the Postgres community is helpful. Postgres is an open source project with multiple layers and locations of community. Membership is open, free, and no invite is needed.

Prefer having an invite? You're invited!

Continue Reading

PostGIS Day 2022 is tomorrow, was November 17th. I am excited to be giving a talk at this year's PostGIS Day virtual event hosted by Crunchy Data!

The recording to this talk is on the Crunchy Data's YouTube page! Downloads are below.

My talk, Route the Interesting things (not just roads!) with OpenStreetMap, is scheduled for 2:00 PM Mountain Time. The full schedule is available on Crunchy Data's website. The original purpose of this post is to provide resources I will reference in my talk today. If you're here for those resources, feel free to skip to the Downloads and Links sections below.

The other purpose for this post is to provide a last minute announcement for this year's PostGIS Day talks and speakers. There are a lot of great talks scheduled! Register now, there's still time, it's virtual, and free!

What I'll be watching

PostGIS Day is an all-day, 12 hour, 24 session marathon of PostGIS related talks. I plan to attend PostGIS sessions from start to finish this year, with small breaks in there for a bit of real life. As I read through the schedule I find myself saying "That'll be interesting" and "I wonder how..." It's a seriously great lineup!

It was tough to choose the top-5 list of talks I don't want to miss. I had to firmly apply a "How will I use this today?" filter to narrow it down.

• Vicky Vergara: How to Prepare a Graph for pgRouting
• Krishna Lodha: Creating APIs from PostGIS with Django and GeoAlchemy
• Aliaksandr Kalenik: GiST Index Building in PostgreSQL 15
• Bonny Mcclain: Once upon a database... Telling stories with PostGIS and QGIS
• Greg Smith: Speedrunning the Open Street Map osm2pgsql Loader

Continue Reading

This blog post is for PGSQL Phriday #002. Read Ryan Booz' introduction from September for more details on PGSQL Phriday. Andreas Scherbaum is this month's host and chose the topic: Postgres backups!

The topic reposted here:

Which tool(s) are you using, where do you store backups, how often do you do backups? Are there any recommendations you can give the reader how to improve their backups? Any lesser known features in your favorite backup tool? Any new and cool features in a recently released version?

Bonus question: Is pg_dump a backup tool?

What is a backup?

I address most of ads' questions in this post, but before we dive in we need to define "backup." Merriam Webster has a definition for backup in the context of computers:

backup (3): "a copy of computer data (such as a file or the contents of a hard drive)"

I'm running with this simple defintion of backup for today's post. To frame the definition of "backup" in a non-Postgres context: Suppose I have a "business document." I want to make some major changes but am afraid of accidentally losing something important. What do I do? I copy / paste the file, change the name to include today's date, and edit away. Did I create a backup of the original document? Sure. In a way. Is it the same thing as when the IT department backs up the network drive the documents where both the original and newly modified files are saved? Nope. Do both approaches serve their purpose? Yes!

Database backups are similar. There isn't a one-size-fits-all solution.

Continue Reading

One of my favorite layers to route with pgRouting is the water layer. I am interested in where water comes from, where it goes, where runoff happens, and how urban development interacts with this powerful force of nature. The OpenStreetMap water layer, however, presents a challenge when routing with PostGIS and pgRouting: Polygons.

Why are polygons a challenge? A routing network using pgRouting is built from lines (edges). Now, to state the obvious: polygons are not lines.

Real world waterway networks are made up of both lines and polygons. Rivers, streams, and drainage routes are predominately (but not exclusively!) mapped using lines. These lines feed into and out of ponds, lakes, and reservoirs. The following animation shows how much impact the water polygons can have on a waterway network... some very important paths simply disappear when they are excluded.

To make the full water network route-able we need to create a combined line layer. The combined line layer will include:

• Initial osm.water_line inputs
• Medial axis lines from osm.water_polygon
• Lines to connect initial inputs to medial axis

Continue Reading