BonesMoses.org

People are so blind to their own flaws.

In the lonely hint of darkness, for there are nor wit nor wail.

Dear subhuman filth, I know you’re probably too busy fornicating with your toothless inbred sister to read this, and your unkempt diaper-strewn trailer likely isn’t compatible with such technological advancements such as the internet, but we need to talk,…

To support more of my tinkering in an effort to test various Postgres cluster configurations, I decided it would be really nifty to have a virtual server.

Postgres is one of those database engines that carves out a niche and garners adherents with various levels of religious zeal.

The Postgres system catalog is a voluminous tome of intriguing metadata both obvious and stupendously esoteric.

Recently on the pgsql-performance mailing list, a question popped up regarding Postgres RAM usage.

MySQL has had a REPLACE INTO syntax to perform “UPSERT” logic since practically the very beginning.

Last week we explored using Postgres as a central communication nexus between several data sources.

Earlier this year, I implied Postgres was some kind of super middleware for dragging data out of every external resource it could locate.

Now that we know how Postgres window functions work, why not play with them a bit to get a better understanding of their capabilities?

I’ll be the first to admit that I found Postgres window functions fantastically confusing when I first encountered them.

There are a lot of languages available for authoring Postgres functions, but there’s nothing quite like the the classic PL/pgSQL.

I’ve been an active Postgres user and advocate since 2001, but didn’t really dive in until 2005.

These days with multiple Postgres database environments a commonality, it’s not unheard of to copy data from one to another.

In light of recent events where GitLab suffered a massive database loss, this is a great opportunity to examine what happened from a Postgres perspective.

Foreign tables have been a headline feature of Postgres ever since the release of version 9.2.

Not a lot of people remember what Postgres was like before version 8.4.

There are a smorgasbord of database engines out there.

Postgres is great, but it can’t run itself in all cases.

Recently a coworker asked me this question: Should I expect variance between minutes and hours for the same query?

It’s about the time for year-end performance reviews.

One of the best features Postgres boasts is the ability to adapt.

The Postgres query planner is house of cards built upon the ever-shifting sand of our data.

The United States held an election recently, and there has been some … mild controversy regarding the results.

I know a lot of people watched the election results in disbelief last night, or woke up this morning and thought something like this: There’s a bit of sad truth there.

Through the wonderful magic of corporate agreements, I’ve been pulled back into (hopefully temporarily) managing a small army of MySQL servers.

Partitioning tables in Postgres can be an extremely risky endeavor.

One of the things Postgres has been “missing” for a while is logical replication based on activity replay.

For all of those warehouse queries that never seem to complete before the heat death of the universe, there’s often a faster version.

Timing can often be extremely fortuitous.

When it comes to putting Postgres through its paces, we often turn to benchmarks to absolutely bury it under a torrent of oppressive activity.

There seem to be quite a few popular Postgres conferences peppering the globe these days.

There’s a bit of loneliness in the world, I think.

Say hi to Princess Kittybutt.

It’s no surprise Postgres does more than merely store data; you can’t do everything with SQL.

All database engines, even Postgres, occasionally present a seemingly intractable problem that will drive everyone insane while attempting to isolate it.

“Hey!

Occasionally with a lot of similar-sounding terminology, there’s ample room for misunderstandings.

We’ve all had it happen.

The pure, unadulterated, presumptuous impudence of NoSQL.

I’ve been almost exclusively a Postgres DBA for a seemingly interminable length of time.

Naming objects in a database can sometimes be an exercise in frustration.

Like any programming language, the PL/pgSQL Postgres procedural language has plenty of handy control structures.

On a higher level, Postgres has a bevy of libraries, interfaces, and clients for accessing a database instance.

One way the Postgres project is subtly misleading, is that it becomes easy to forget that not all other projects are nearly as well managed.

There comes a day in every young database’s life that it’s time to move on.

Ah, source control.

Now that we’ve decided to really start embracing horizontal scaling builds, there is a critically important engine-agnostic element we need to examine.

I always advocate breaking up large Postgres tables for a few reasons.