pgMustard Pro now includes 1,000 API credits 🎉
Bulk-analyse plans, plug into your LLM workflows, or build something we haven't thought of yet.
Docs: pgmustard.com/docs#api
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...
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.
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
If you have any Postgres performance issues, I'd love to hear about them and try to help: pgmustard.com/office-hours
If pgMustard has made your life easier this year, we'd love a review on G2! It does take a few minutes, but we like that it is verified, and are already using the feedback to shape what we work on next.
www.g2.com/products/pgm...
A screenshot of pgMustard, focused on a tip that reads: "Row Estimate: out by a factor of 120. The query planner estimated that this operation would produce 283,853 rows per iteration, but it actually produced 2,444 (out by a factor of 120). Bad row estimates can lead to suboptimal query plans. They can often be improved by running ANALYZE on the tables involved, by increasing column statistics, or by allowing Postgres to assess the correlation between columns (using multivariate statistics)."
Bad row count estimates are a common cause of slow queries.
We've had a tip for them in pgMustard from the start, but we've just finished a revamp of it, mostly to make the advice in several common cases clearer. We also now report the ratios a little more naturally.
A chart showing 48% on 17 or 18, 42% on 15 or 16, 10% on 13 or 14, and nobody (admitting to being) on 12 or older
It was a very small sample size, but we were impressed with the number of people running newer Postgres versions in our recent poll 🙌
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)
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
I think @pgmustard.com is great for actionable recommendations for EXPLAIN results. Still helps me a ton to figure things out to this day.
What are your favorite PostgreSQL-specific resources to use as part of providing some technical mentorship to a junior developer?
Which major version of PostgreSQL are you (primarily) running in production?
Screenshots of the BUFFERS page before and after, with the following text highlighted: "And from Postgres 18, it is on by default with ANALYZE."
We're in the process of updating our EXPLAIN glossary for Postgres 18.
This change was particularly satisfying 🎉
Great write-up by Michael Christofides from @pgmustard.com
www.pgmustard.com/blog/what-do...
> It turns out that for the general case, boundary conditions and NULLs (of course!) always need to be considered, so you can get one or two extra Index Searches when these can’t be ruled out
#postgresql
Thank you Benoit (and credit of course to Peter G for enlightening me on that part) — Michael
Thanks again for the idea Andy, blog post published, let us know if it could be clearer or more useful — Michael
www.pgmustard.com/blog/what-do...
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...
A screenshot of the pgMustard YouTube channel, showing 8 new videos, one per tool. They range from 2 minutes to 10 minutes in length.
The next chapter in our 7-year battle with EXPLAIN formatting: new demo videos showing how to get nicely formatted query plans in your tool of choice.
www.youtube.com/@pgMustard
Sorry for the slow reply! We're about to embark on updating our explain glossary for 18, and adding a page for "Index Searches" is top of the list. A blog post is probably a good idea too, thank you 🙏
Check out the interview with Supporter sponsor @pgmustard.com posted at 2025.pgday.uk/sponsor-inte...
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. 💛
There are a couple of online #PostgreSQL events today that look like they'll be great:
16:00 UTC — 10 Costly Database Performance Mistakes (and How to Fix Them) with Andy Atkinson www.meetup.com/postgres-mee...
19:00 UTC — 12 years of Postgres Weekly with Peter Cooper aka.ms/TalkingPostg...
Hello, Bluesky!
