PGSQL Phriday #001 – Two truths and a lie about PostgreSQL

Welcome to the inaugural invite of #PGSQLPhriday, a new, monthly blogging event for the larger PostgreSQL community! Each month, a different member of the PostgreSQL community will act as the host, choose the topic, and write an invite post similar to this. Once the blog posts are contributed, the host will write a wrap-up of all the contributions. What a great way to share your knowledge with other PostgreSQL users!!

(The topic for this first event is explained a bit further 👇, after a brief detour to discuss the last-minute name change.)

Hold on, I thought this was #PSQLPhriday?

OK, you caught me. Probably one of the worst things to do on the inaugural invite is to change the event’s name. 😬 The truth is, since announcing the idea, a few different community members expressed concerns about “psql” (rather than “pg”) and “phriday” (rather than “Friday”). They’re all valid concerns, and it’s hard (for me) not to want to accommodate everyone.

Because this idea is taken from the SQL Server community and #TSQLTuesday, I wanted to give a nod to that long-running event, and “psql” (no “G”) seemed like a natural fit. But “psql” is a bit overloaded too because of the 💯 command line tool of the same name, so there was a small chance that name could cause some confusion.

And so this weekend, as I debated what to do, I realized that all of the official PostgreSQL mailing list names used “pgsql” as the prefix. Sticking with this same prefix still allows the event to (subtly) give a tip of the hat to the original TSQL Tuesday event while still pointing to the decades of hard work and collaboration that has occurred on the mailing lists, a place where so much history of Postgres is documented and available.

And so, #PGSQLPhriday it is. No exchanges this time, I promise.

Thanks for understanding!

Choosing a topic for the inaugural event

I’m not going to lie. It’s been challenging for me to pick the first topic to get this party started. I seem to gravitate to topics that are too broad (“Why do you love Postgres 15?”), or too narrow (“Tell us about your best contribution to PostgreSQL”). In the original announcement post, I even hinted that the topic would simply be “Why Postgres?”

I also realize that this first event comes at a unique time in the PostgreSQL lifecycle: many folks just attended PGConf NYC 2022, PostgreSQL 15 is being released on October 13, and PGConf EU is October 25-28 in Berlin. A lot is happening right now, and any of these special milestones could be inspiration for an interesting topic. (“Which PostgreSQL 15 feature are you most excited about?”, “What have you enjoyed most about attending in-person conferences again?”)

But as I contemplated the topic (for far too long…), I recalled one of the more unique talks I was able to attend at PGConf NYC given by Ilya Kosmodemiansky, “PostgreSQL Worst Practices.” In his presentation, Ilya provided insights into many configuration and development issues folks run into with PostgreSQL by admonishing us to do the “worst” practice. (ie. “Absolutely don’t take regular backups of production, but if you do, only use pg_dump”) It was a clever and humorous presentation that provided good laughs and great dialog about true best practices.

So that got me thinking about some clever ways we could share tried and true PostgreSQL development and configuration tips with one another. If you spend any time on Twitter, the mailing lists, or Postgres Slack, there is no shortage of questions about common configuration and development best practices. While some folks have written blog posts to address these common questions over the years, there is always room for others to contribute.

Your mission, should you choose to accept it…

For this first event, I want you to write a blog post that shares three of your go-to Postgres best practices, but write it in the form of the game Two truths and a lie.

For example, perhaps there are three configuration settings you always modify whenever setting up a new cluster. You could share why these settings are important to modify and how you find the correct values, but for one of them, use Ilya’s comical approach to teach us the correct way to set the value. (ie. “I never set shared_buffers to more than 128MB to conserve server resources.” 😱)

Maybe you have three go-to ways of monitoring your cluster or multiple SQL options to overcome a tricky query problem many PostgreSQL developers face. You’re limited only by your imagination.

And obviously, at the end of the blog, be sure to clearly identify which of the three tips was a lie and how someone should actually modify the setting or write that tricky SQL statement. 😉

How to contribute your blog post

There are only a few “rules” that we ask everyone to follow when writing a blog post to contribute each month.

• Use “PGSQL Phriday #001”/”#PGSQLPhriday 001” in the title or first paragraph of your blog post. (the number will change each month)
• Link back to this invite. (ie. “For #PGSQLPhriday 001, Ryan asked us to…”). If you don’t link back to the invite, you won’t be included in the summary list of blog posts.
• Post your blog sometime on Friday, October 7, 2022. The world is a big place, so if it’s a little early or late… it’s probably still Phriday somewhere! 😃
• Announce your blog post in at least one of the following places:
  • Twitter (preferred), using the #PGSQLPhriday hashtag
  • PostgreSQL Slack in the #pgsqlphriday channel
  • Responding to the thread on the pgsql-general email list that announced this month’s blog topic
• Read other blog post contributions and encourage the authors. Remember, the goal is to increase community involvement and knowledge sharing

I can’t wait to see what you contribute on Friday, October 7, 2022! 🎉🎉🎉