171–180 of 293 posts
Here we are, at a fantastic version 14, and still no sign of an MySQL AB-like company able to provide support and extensions to a great piece of open source software. There's a few small ones, yes, but nothing at the billion dollar size. I am still unable to understand why.
Earlier quoted context omitted.
They are slowly getting there. For example, postgres 12 added REINDEX CONCURRENTLY. Under the hood it's just recreating the index and then name swapping and dropping the old one. Basically what pg_repack was doing. There's a huge collection of tricks out there that just need to become formal features. The trick I'm working with today is adding a check constraint with NOT VALID and then immediately calling VALIDATE be…
Do you know a good resource with these tricks? I often struggle to predict exactly which schema migrations will lock tables aggressively and what the smartest workaround is.
Earlier quoted context omitted.
> If I may hijack the thread with some more general complaints though, I wish the Postgres team would someday prioritize migration. A thing I'm interested in is a 'simple' replication setup to reduce single points of failure. We currently use Galera with My/MariaDB/Percona and it's quite handy for HA-ish needs: we can have two DBs and the garbd running on the web app server. Pointers to tutorials for Debian/Ubuntu to…
There's no such thing as "simple" when it comes to HA setups, the requirements are simply too varied. PostgreSQL has great documentation for their HA featureset, but when it comes to systems-level concerns (detecting that a primary is down and arranging promotion of a replica to primary) you're expected to address those on your own.
PostgreSQL is one of the most powerful and reliable pieces of software I've seen run at large scale, major kudos to all the maintainers for the improvements that keep being added. > PostgreSQL 14 extends its performance gains to the vacuuming system, including optimizations for reducing overhead from B-Trees. This release also adds a vacuum "emergency mode" that is designed to prevent transaction ID wraparound Dealin…
> Also it is possible but highly inadvisable to disable auto-vacuums. When I was running my first Postgres cluster (the reddit databases), I had no idea what vacuuming was for. All I knew was that every time it ran it slowed everything down. Being dumb, I didn't bother to read the docs, I just disabled the auto vacuum. Eventually writes stopped and I had to take a downtime to do a vacuum. Learned a few important less…
Somewhat related, but does anybody have suggestions for a quality PostgreSQL desktop GUI tool, akin to pgAdmin3? Not pgAdmin 4, whose usability is vastly inferior. DBeaver is adequate, but not really built with Postgres in mind.
If you’d like to try out PostgreSQL in a nice friendly hosted fashion then I highly recommend supabase.io I came from MySQL and so I’m still just excited about the basic stuff like authentication and policies, but I really like how they’ve also integrated storage with the same permissions and auth too. It’s also open source so if you can to just host it yourself you stil can. And did I mention they’ll do your auth fo…
[Supabase cofounder] thanks for the kind words. We're about to wrap up Row Level Security on our real-time APIs too[0] - soon you'll be able to use Policies universally on all APIs. [0] https://github.com/supabase/walrus
Anyone know where to download it? Looks like they haven't updated the download pages, even though they link to them at the end of this post.
These changes look fantastic. If I may hijack the thread with some more general complaints though, I wish the Postgres team would someday prioritize migration. Like make it easier to make all kinds of DB changes on a live DB, make it easier to upgrade between postgres versions with zero (or low) downtime, etc etc. Warnings when the migration you're about to do is likely to take ages because for some reason it's going…
We currently use MongoDB and while Postgres is attractive for so many reasons, even with Amazon Aurora's Postgres we still need legacy "database maintenance windows" in order to achieve major version upgrades. With MongoDB, you're guaranteed single-prior-version replication compatibility within a cluster. This means you spin up an instance with the updated version of MongoDB, it catches up to the cluster. Zero downti…
Earlier quoted context omitted.
> Also it is possible but highly inadvisable to disable auto-vacuums. When I was running my first Postgres cluster (the reddit databases), I had no idea what vacuuming was for. All I knew was that every time it ran it slowed everything down. Being dumb, I didn't bother to read the docs, I just disabled the auto vacuum. Eventually writes stopped and I had to take a downtime to do a vacuum. Learned a few important less…
Everytime I've seen people having "vacuuming too expensive" problems, the solution was "more vacuum"!