Michael Christofides

@michristofides.com

Half of the team behind @pgmustard.com and (a different) half of the team behind Postgres FM

New blog post: Read efficiency issues in Postgres queries If you've got a query that's slowly degrading in performance, you might have a read efficiency issue. The root cause could be table bloat, index bloat, or data locality degradation. www.pgmustard.com/blog/read-ef...

Read efficiency issues in Postgres queries - pgMustard

A lot of the time in database land, our queries are I/O constrained. As such, performance work often involves reducing the number of page reads. Indexes are a prime example, but they don’t solve every...

pgmustard.com

Our Read Efficiency tips are now more efficient to read! 📝 Better wording, mostly for clarity 🔬 More specific to the scan type, and therefore shorter in most cases 🌟 Improved scoring, especially for Bitmap Heap Scans More details: www.pgmustard.com/changelog

A screenshot of two pgMustard windows, with an example query plan in each, and an arrow pointing from the old version to the new. Each has a Bitmap Heap Scan highlighted, and the Read Efficiency tip expanded.

We've revamped our "Operation on Disk" tips ✨ * Made them clearer * Made them more succinct (in most cases) * Improved the scoring * Mention hash_mem_multiplier (when relevant) * Show "Operation in Memory" in more cases, with the memory used * Updated the linked blog post

A side my side comparison highlighting mostly how much more succinct a new version of the tip can be. The tip wording of the new version is as follows:

This operation wrote out to disk to store temporary data.

Disk space used: 282 MB

Reducing the size of the operation would make it faster, especially if you can get it to fit into working memory.

You can do this by reducing the number of rows, with a LIMIT clause, or reducing the size of each row, by operating on fewer columns.

Another option is to increase the memory available, by adjusting work_mem.

Learn more about working memory (underlined, as it's a link)

Big performance problems 🤝 tiny CS tricks Our latest blog breaks down how bloom filters helped us take an API from 5s to 0.3s - even with millions of alerts in play. If you’re fighting slow queries or Postgres under pressure, this one’s worth a look: go.incident.io/r9jgcI9

Bild

I'm not sure @ankane.bsky.social is human - maybe some kind of open source being from the future 😂 I said to a colleague - "we'll see, but it's ankane, so it's entirely possible it'll get done soon". Less than an hour later, it was updated 🤯

Bild

New blog post: "What do the new Index Searches lines in EXPLAIN mean?" In Postgres 18 you'll start seeing things like "Index Searches: 1" on each of your index scans. We looked into what they mean, and how that information can be helpful. www.pgmustard.com/blog/what-do...

What do the new Index Searches lines in EXPLAIN mean? - pgMustard

In Postgres 18 you’ll now see “Index Searches” lines in EXPLAIN ANALYZE output. If like me you were wondering what those mean exactly, you’re in the right place.

pgmustard.com

The upcoming Postgres 18 is set to include some nice improvements to EXPLAIN: * BUFFERS on by default with ANALYZE 🎉 * Fractional "actual rows" (huge in some cases) * Quite a few new fields (including the very cool Index Searches) We've now added support for all of them. 💛

Next week (14th) I'll be joining the excellent Postgres Meetup for All to demo and discuss troubleshooting slow queries using EXPLAIN and external tools: www.meetup.com/postgres-mee... If you or your team could do with an intro or refresher, it would be great to see you there!

Postgres Meetup for All | Meetup

Calling all Postgres enthusiasts! Do you work with Postgres? Do you want to be more involved in the community? Share your learnings? Join our vibrant online community dedicated to PostgreSQL, the worl...

meetup.com