Live data from Hacker News

Looking Ahead to Postgres 19

snowflake.com

131–138 of 138 posts

Re: Looking Ahead to Postgres 19

#131
post #127

I've used postgres on a few projects (via AWS rds) but I've always used it as a pretty vanilla SQL database. Probably the most "fancy" feature I've used being bson columns. Can anyone recommend good resources for going deeper? (Obviously I could Google, but I appreciate HN recommendations)

postgres is as wide as the ocean when it comes to features. Without any specifics of what you're looking for, theres not much to suggest.

Re: Looking Ahead to Postgres 19

#132

Earlier quoted context omitted.

I think we take for granted how few databases ever outgrow vertical scaling needs. Usually there will be one or two tables that grow at a dramatically faster rate than everything else and I have always found that those belong in a separate data store.

You need replication for HA. Otherwise the only HA you have is the RAID setup on the one machine. The reason people go horizontal is rarely scale. And if you're doing that you might as well use the passive replica as a read replica.

Read replication is easy.

Horizontal scaling for DB typically means distributing the write load across instances either via sharding or master-master. I could be wrong of course, but that’s how I read it.

MySQL is very good at master-master out of the box.

Re: Looking Ahead to Postgres 19

#133

Earlier quoted context omitted.

You need replication for HA. Otherwise the only HA you have is the RAID setup on the one machine. The reason people go horizontal is rarely scale. And if you're doing that you might as well use the passive replica as a read replica.

Read replication is easy. Horizontal scaling for DB typically means distributing the write load across instances either via sharding or master-master. I could be wrong of course, but that’s how I read it. MySQL is very good at master-master out of the box.

To be pedantic, master-master implies the same row can be committed to at the same time at different master nodes (without an immediate causal connection between the two). Very few databases allow this.

Re: Looking Ahead to Postgres 19

#134
post #6

Earlier quoted context omitted.

I get it's in vogue to take stabs at whether or not AI was used. But I think the more useful approach is to instead be critical of the end product, if you have criticisms of it.

This IS a criticism of the end product.

I don't think most people would consider the writing style of a postgres article to be the 'end product' of that article.

Re: Looking Ahead to Postgres 19

#136
post #95

Earlier quoted context omitted.

> Synchronously updated materialized views... Oh yes, I'd love them too (if you're referring to, in Oracle slang, "...update on commit") - and it would be cool to have as well the option for a lazy update ("on demand" by taking into consideration only the records that have been changed since the last refresh, to handle multiple updates in a single pass - not sure how Oracle can achieve that technically...). This woul…

Clickhouse offers the same through https://clickhouse.com/docs/materialized-view/incremental-ma... . I personally LOVE this feature and concur with the gp that they're really elegant solutions to difficult problems. Just to give an example, I ingest otel trace spans individually and in a materialized view calculate the total duration of the whole trace among other things.

Its not transactional or atomic.

Re: Looking Ahead to Postgres 19

#137
post #66
post #29

Earlier quoted context omitted.

>I do myself a favor and always avoid Oracle and MySql/MariaDB. So what's wrong with MySQL or MariaDB?

And although you didn't ask, I'll list what's wrong with Oracle. It's very simple. Oracle treats empty strings as being NULL . Anyone who's never used Oracle before in their life is probably wondering if I'm making it up. I'm not. In Oracle, inserting '' in a VARCHAR column is exactly the same as inserting NULL. And if there's a NOT NULL column, you're not allowed to store the empty string in there. Which means that…

>Sorry. Had to get that off my chest. I know I'm answering a question you didn't ask,

Not at all. Thank You for sharing it and didn't put another morale rant about Oracle. Hopefully someone reads it and provide some interesting back stories.

Re: Looking Ahead to Postgres 19

#138
post #85
post #29

Earlier quoted context omitted.

>I do myself a favor and always avoid Oracle and MySql/MariaDB. So what's wrong with MySQL or MariaDB?

1. No transactional DDL 2. No MERGE statement 3. No partial indices 4. Many ways to lock out instant add table, meaning you can’t add a column without a full table write, which can lock the table for minutes at a time in even moderately sized tables. 5. Dealing with legacy mysql databases often means dealing with utf8mb3, which used to be the default utf8 data type despite not storing all utf8 6. Dealing with all but…

These issues are similar to a comment below. But a lot of these are fixed in recent version of MySQL or handled with Vitess.
Post reply on HN