Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL 14

postgresql.org

Post reply on HN
Print view View original

141–150 of 293 posts

Re: PostgreSQL 14

#141

Post by oauea »

tomhallett wrote: post #116
smileysteve wrote: post #108

Earlier quoted context omitted.

logical replication, but this is one of the walls that heroku creates.

Coming from the outside, with zero understanding of the internal details, my hunch is the same: lack of support for logical replication is more of a business decision than a technical decision. (But again, this a hunch -- partially based on how good heroku is from a technical perspective)

It's absolutely an evil business decision, and all the clouds are playing this game. Don't ever use a hosted database solution if you're thinking about storing any significant amount of data. You will not be able to get it out without downtime.

Re: PostgreSQL 14

#142

Post by polskibus »

hyper_reality wrote: post #46
darksaints wrote: post #37

Earlier quoted context omitted.

What is wrong with using a 64 bit, or even 128 bit transaction id?

It would increase disk usage by a significant amount, since transaction IDs appear twice in tuple headers (xmin/xmax). Essentially they are overhead on every database row. This submission has a discussion on it: https://news.ycombinator.com/item?id=19082944

I wonder how does MS SQL work differently.

Re: PostgreSQL 14

#143

Post by kiwicopple »

yawnxyz wrote: post #80
kiwicopple wrote: post #28

Earlier quoted context omitted.

[supabase cofounder] While we position ourselves as a Firebase alternative, it might be simpler for experienced techies to think of us as an easy way to use Postgres. We give you a full PG database for every project, and auto-generated APIs using PostgREST [0]. We configure everything in your project so that it's easy to use Postgres Row Level Security. As OP mentions, we also provide a few additional services that y…

as a product designer, I've been with Supabase since its inception. You guys make projects so easy to start prototyping, without me having to think about starting a Postgres droplet or whatever. Thank you so much for making Supabase better every day!!

Thanks for joining us for the ride!

Re: PostgreSQL 14

#144

Post by 0XAFFE »

illuminated wrote: post #70
mypastself wrote: post #30

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.

PgModeler [0], cannot recommend it enough. You have to compile yourself the free version (it's open source - you pay if you want to directly download the precompiled binaries) and it's a bit of work if you want to include the query optimizer plugin, but there's documentation and GitHub issues with solutions already in place. Once you compile it for the first time and start using it, you'll keep doing it again with ea…

I really like the diff function to generate migrations. Make changes to your model and generate a sql file that syncs your database to the model.

Re: PostgreSQL 14

#145

Post by Tostino »

garyclarke27 wrote: post #83

Fantastic piece of software. The only major missing feature that I can think of is Automatic Incremental Materialized View Updates. I'm hoping that this good work in progress makes it to v15 - https://yugonagata-pgsql.blogspot.com/2021/06/implementing-i...

This has been a major one i've wanted for a long time too, but sadly it's initial implementation will be too simple to allow me to migrate any of my use cases to use it.

Re: PostgreSQL 14

#146

Post by TedShiller »

bmcahren wrote: post #81
skrebbel wrote: post #63

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…

The problem with MongoDB though is that you're on MongoDB

Re: PostgreSQL 14

#147

Post by abdusco »

postgresapp wrote: post #5

If you want to test the new features on a Mac, we've just uploaded a new release of Postgres.app: https://postgresapp.com/downloads.html

I love this app on Mac, but I wonder if there is a similar app for Windows (i.e. portable Postgres)?

Re: PostgreSQL 14

#148

Post by throw0101a »

skrebbel wrote: post #63

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…

> 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 accomplish something similar would be appreciated. (We run things on-prem in a private cloud.)

Re: PostgreSQL 14

#149

Post by throw0101a »

dylanz wrote: post #101
buro9 wrote: post #23

Suppose I had a "friend" with a PostgreSQL 9.6 instance (a large single node)... what's the best way to upgrade to PostgreSQL 14?

If you're on a single node, probably something like this. This is what my "friend" is doing later this week. He's migrating from 9.5 to 13: sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list' wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - sudo apt-get update sudo apt install postgresql-13 sudo servi…

> wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

Is there a reason to do this rather than putting the key in /etc/apt/trusted.gpg.d/?

Re: PostgreSQL 14

#150

Post by Tostino »

olavgg wrote: post #61
buro9 wrote: post #23

Suppose I had a "friend" with a PostgreSQL 9.6 instance (a large single node)... what's the best way to upgrade to PostgreSQL 14?

This is one of the major pain points with PostgreSQL. Unless you absolutely need any new features and uptime is important, you can just continue using PostgreSQL 9.6 even thought it is EOL. https://www.postgresql.org/support/versioning/ It will most likely work great for many more years. I wish future versions of PostgreSQL will have some backwards compatibility for old system/data tables/datastructures and be able t…

This is not really true for a number of reasons. pg_upgrade is absolutely the preferred method if you are able to spare small downtime. It will absolutely work to upgrade your existing data structures to be compatible with the new Postgres version, so not sure what you even mean.

It doesn't automatically re-create indexes (to take advantage of new features) for example, but that is likely something you don't want to do right away (incurring extra downtime) when you are doing an upgrade anyways. You can easily just REINDEX after the upgrade is complete.

Post reply on HN