"Right size" your PostGIS data
PostgreSQL is my database of choice; skydiving is my adrenaline rush of choice!
I started my technology-heavy career in 2003 working in the professional audio industry from a computing perspective. By 2008 I had become fully immersed in the world of databases, programming, and automating away tedious data-related tasks for the office. PostGIS was the driving force behind my initial use, and eventual love, of PostgreSQL.
The PostGIS extension turns Postgres into the world's most advanced open source spatial database. Not all DBA's are experienced with spatial data or spatial analysis and that can cause misunderstandings and performance problems. The core problem is often a problem with how the spatial data is loaded and provided to analysts. This presentation provides practical examples of how to understand and structure your spatial data with performance as a quality metric. It's well-known that we can structure sales data for transactional processing (normalized, OLTP), and we can transform that data into better formats for reporting purposes (OLAP). The same concepts apply to spatial data!
This talk helps demystify the cause of many performance issues related to spatial data. These problems often can be fixed by understanding and restructuring your spatial data appropriately.
ST_MemSize(), and other database best practices can be used to resolve many common headaches. Understanding GIS analysts and their software helps with the rest. Concepts discussed in this talk are outlined my two
PostGIS: Tame your spatial data blog posts (Part 1, Part 2).
- 2019 March 20 13:00
- 50 min
- Sugar Hill
- Postgres Conference