# Jeremy Schneider - A Hairy PostgreSQL Incident (Highlights) ![rw-book-cover|256](https://readwise-assets.s3.amazonaws.com/static/images/article2.74d541386bbf.png) ## Metadata **Cover**:: https://readwise-assets.s3.amazonaws.com/static/images/article2.74d541386bbf.png **Source**:: #from/readwise **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Jeremy Schneider]] **Full Title**:: A Hairy PostgreSQL Incident **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [ardentperf.com](https://ardentperf.com/2022/02/10/a-hairy-postgresql-incident/) **Host**:: [[ardentperf.com]] **Highlighted**:: [[2022-03-11]] **Created**:: [[2022-09-26]] ## Highlights - Unlike some other relational databases, PostgreSQL does not give much visibility into execution plans used at runtime. There’s auto_explain which can log actual plans for SQL that successfully completes with a runtime above some threshold. ([View Highlight](https://instapaper.com/read/1489127734/19012596)) - Joshua left a comment reminding me about Cybertec and Hironobu Suzuki’s extension pg_show_plans. ([View Highlight](https://instapaper.com/read/1489127734/19012597)) - We have a script of our own which is very similar to Tanel Poder’s run_xcpu.sh in his 0x.tools collection. ([View Highlight](https://instapaper.com/read/1489127734/19012606)) `run_xcpu.sh` in his [0x.tools collection](https://0x.tools/)