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

Looking Ahead to Postgres 19

snowflake.com

Post reply on HN
Print view View original

101–110 of 138 posts

Re: Looking Ahead to Postgres 19

#101

Post by kiwicopple »

eatonphil wrote: post #59
znpy wrote: post #54

Earlier quoted context omitted.

I was about to post something similar. There was a big fanfare about orioledb a while ago, and i think it got bought by people that wanted to push that into mainstream postgres? Did it die somewhere along the road?

Supabase customers run it (marked alpha). https://supabase.com/blog/orioledb-launch And they continue to work on it. https://supabase.com/blog/orioledb-patent-free

(supabase employee)

confirming that we're still working hard on this. aiming to be production-ready this year. benchmarks and compatibility testing are on track

Re: Looking Ahead to Postgres 19

#102

Post by sgarland »

mickeyp wrote: post #44

The graph database feature looks interesting, but I wonder... SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name)); That is _awful_ syntax; it is reminiscent of neo4j, which is surely not a tool anyone serious should copy from outright in 2026. And of course the final thing I am left wondering is…

> [RLS]… planner goes haywire and does per-row-matching

Er… yes? It’s called Row-level security; how else are you going to validate that a row passes a policy?

Re: Looking Ahead to Postgres 19

#103

Post by [deleted] »

aljgz wrote: post #14

I've used Postgres, Oracle, MsSql Server, and MySql in serious projects, no extensive experience with Sqlite, which I know is an amazing player. These days, I do myself a favor and always avoid Oracle and MySql/MariaDB. Postgres is amazing, and the two big things I wished it had: 1. lightweight connection; connection bouncers improve the situation, but you still have an unreasonably high memory footprint per concurre…

[deleted]

Re: Looking Ahead to Postgres 19

#104

Post by rmunn »

johnisgood wrote: post #94
rmunn wrote: post #66

Earlier quoted context omitted.

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…

> Oracle treats empty strings as being NULL. That is ridiculous. Do not they know the difference between "" and NULL?

I'm pretty sure the historical reasons I mentioned involved creating the software before the SQL standard came out, meaning they were treating NULL as meaning "nothing", instead of meaning "unknown" as the SQL standard requires. But that's as far as I care to go digging into a database system I will never use of my own free will.

Re: Looking Ahead to Postgres 19

#105

Post by brightball »

khurs wrote: post #88
aljgz wrote: post #14

I've used Postgres, Oracle, MsSql Server, and MySql in serious projects, no extensive experience with Sqlite, which I know is an amazing player. These days, I do myself a favor and always avoid Oracle and MySql/MariaDB. Postgres is amazing, and the two big things I wished it had: 1. lightweight connection; connection bouncers improve the situation, but you still have an unreasonably high memory footprint per concurre…

Postgresql is the better product, but doesn't have the horizontal scaling of MySQL/Maria though, so if you want an easy to setup cluster MySQL for high volume online retail store or similar has a use case still.

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.

Re: Looking Ahead to Postgres 19

#106

Post by kjs3 »

rmunn wrote: post #66
ksec wrote: 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…

I'll list what's wrong with Oracle

Very interesting (and hopefully cathartic). I never got past "it involves doing business with Oracle".

Re: Looking Ahead to Postgres 19

#107

Post by ballon_monkey »

asah wrote: post #33
aljgz wrote: post #14

I've used Postgres, Oracle, MsSql Server, and MySql in serious projects, no extensive experience with Sqlite, which I know is an amazing player. These days, I do myself a favor and always avoid Oracle and MySql/MariaDB. Postgres is amazing, and the two big things I wished it had: 1. lightweight connection; connection bouncers improve the situation, but you still have an unreasonably high memory footprint per concurre…

two techniques I use with pg: 1. "materialize" the view as a full table, then index that. Any reasonable pipeline/ETL tool can provide incremental updates between tables. Obviously, anything materialized requires considerations around storage, replication, backup/restore, I/O, etc. 2. use a regular VIEW and index (precisely) the underlying expressions mentioned in the view, i.e. so when the view is used, then the ind…

Materialized views in pg with any incremental updates has timing inconsistencies that SQL Server doesn't have.

Re: Looking Ahead to Postgres 19

#108

Post by hilariously »

Macha wrote: post #85
ksec wrote: 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…

If you are talking about SQL Server, the MERGE statement is basically a bug minefield, I wouldn't use it unless I wanted to deadlock myself.

Re: Looking Ahead to Postgres 19

#109

Post by cduzz »

joinjune wrote: post #63
aljgz wrote: post #14

I've used Postgres, Oracle, MsSql Server, and MySql in serious projects, no extensive experience with Sqlite, which I know is an amazing player. These days, I do myself a favor and always avoid Oracle and MySql/MariaDB. Postgres is amazing, and the two big things I wished it had: 1. lightweight connection; connection bouncers improve the situation, but you still have an unreasonably high memory footprint per concurre…

Oracle = Pain, Suffering, High Costs, Litigation, and Human Misery. If it wasn't for non-technical middle management that likes the perks of buying high cost software from vendors that throw nice parties they'd be out of business.

Oracle makes their money by promising the C Suite "give us money and we'll solve your problems." There aren't actually many companies in a position to credibly make that promise.

The oracle database is also actually pretty nice, according to the people I've talked to who use it.

But mostly they play in the 'nobody ever got fired for suggesting' club. These days AWS is the most egregious landlord of that club, but whatever.

Re: Looking Ahead to Postgres 19

#110

Post by SigmundA »

zbentley wrote: post #80
aljgz wrote: post #14

I've used Postgres, Oracle, MsSql Server, and MySql in serious projects, no extensive experience with Sqlite, which I know is an amazing player. These days, I do myself a favor and always avoid Oracle and MySql/MariaDB. Postgres is amazing, and the two big things I wished it had: 1. lightweight connection; connection bouncers improve the situation, but you still have an unreasonably high memory footprint per concurre…

> lightweight connection; connection bouncers improve the situation, but you still have an unreasonably high memory footprint per concurrent connection. Pg connections are definitely heavy, but usually on resources other than memory in my experience. If you configure reasonable dirty reclamation and recycling, the memory numbers are often overstated due to Linux tools’ deceptive fork accounting and shared buffers. Of…

Each PG connection being a whole process does not scale like MSSQL that uses a thread per connection which has a max of 32k per instance.

There are no need for connection poolers in front of MSSQL although it is normal to pool connections in the client application which may hold hundreds open typically in a web server.

This also allows MSSQL to more easily share cached query plans between connections since its just sharing executable code between threads.

For PG to do plan caching it would need to serialize the plan between processes and that would require some significant work since it was never designed that way.

PG has it obvious unix roots using processes instead of threads, MSSQL coming from Windows where new process are expensive and there was no real fork, but threads are cheap uses that approach instead.

Post reply on HN