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)
Looking Ahead to Postgres 19
131–138 of 138 posts
Re: Looking Ahead to Postgres 19
#132Earlier 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.
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
#133Earlier 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.
Re: Looking Ahead to Postgres 19
#134Earlier 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.
Re: Looking Ahead to Postgres 19
#135Re: Looking Ahead to Postgres 19
#136Earlier 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.
Re: Looking Ahead to Postgres 19
#137Earlier 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…
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
#138Earlier 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…