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

Benchmarking Postgres 17 vs. 18

planetscale.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Benchmarking Postgres 17 vs. 18

#41

Post by anarazel »

nopurpose wrote: post #14
anarazel wrote: post #4

Afaict nothing in this benchmark will actually use AIO in 18. As of 18 there is aio reads for seq scans, bitmap scans, vacuum, and a few other utility commands. But the queries being run should normally be planned as index range scans. We're hoping to the the work for using AIO for index scans into 19, but it could work end up in 20, it's nontrivial. It's also worth noting that the default for data checksums has chan…

Then io_uring AIO mode underperformance is even more curious.

It is. I tried to repro it without success.

I wonder if it's just being executed on a different VMs with slightly different performance characteristics. I can't tell based on the formulation in the post whether all the runs for one test are executed on the same VM or not.

Re: Benchmarking Postgres 17 vs. 18

#42

Post by samlambert »

jascha_eng wrote: post #31
saxenaabhi wrote: post #15

Earlier quoted context omitted.

But ephemeral and non-redundant. Am I correct in that using local disk on any VPS has durability concerns?

yeh planetscale loves to flex how fast they are but the main reason they are fast is because they run a full abstraction less than any other cloud provider and this does in fact have trade-offs.

What is wrong with running without lots of abstractions? We are clear about the downsides. The results are clear, you can see the customers love it. We run insane amounts of state safely on ephemeral compute. It's a flex. All I've seen from Timescale people is qqing. Write some code or be quiet.

Re: Benchmarking Postgres 17 vs. 18

#43

Post by samlambert »

saxenaabhi wrote: post #15
cheema33 wrote: post #13

The primary lesson I learned here was this: If you care about performance, don't use network storage. If you are using local nvme disk, then it does not matter if you are using Postgres 17 or 18. Performance is about the same. And significantly faster than network storage.

But ephemeral and non-redundant. Am I correct in that using local disk on any VPS has durability concerns?

we have mitigated the durability concerns in multiple ways.

Re: Benchmarking Postgres 17 vs. 18

#45

Post by samlambert »

cheema33 wrote: post #13

The primary lesson I learned here was this: If you care about performance, don't use network storage. If you are using local nvme disk, then it does not matter if you are using Postgres 17 or 18. Performance is about the same. And significantly faster than network storage.

Correct. Network storage is flexible for a variety of use cases that's why PlanetScale supports both.

Re: Benchmarking Postgres 17 vs. 18

#47

Post by sgarland »

saxenaabhi wrote: post #15
cheema33 wrote: post #13

The primary lesson I learned here was this: If you care about performance, don't use network storage. If you are using local nvme disk, then it does not matter if you are using Postgres 17 or 18. Performance is about the same. And significantly faster than network storage.

But ephemeral and non-redundant. Am I correct in that using local disk on any VPS has durability concerns?

Yes, it’s the ephemerality that’s the biggest issue. Enterprise-grade SSDs are quite reliable, and typically have PLP so even in the event of a sudden power loss, any queued writes that the drive has accepted - and thus ack’d the fsync() - will be written. Presumably you’d be running some kind of redundancy, likely some flavor of RAID or zRAID (assuming purely local storage here, not a distributed system like Ceph, nor synchronous replication).

But in the cloud, if the physical server backing your instance dies, or even if someone accidentally issues a shutdown command, you don’t get that same drive back when the new instance comes up. So a problem that is normally solved by basic local redundancy suddenly becomes impossible, and thus you must either run synchronous or semi-sync replication (the latter is what PlanetScale Metal does), accepting the latency hit from distributed storage, or asynchronous replication and accept some amount of data loss, which is rarely acceptable.

Re: Benchmarking Postgres 17 vs. 18

#48

Post by samlambert »

sgarland wrote: post #47
saxenaabhi wrote: post #15

Earlier quoted context omitted.

But ephemeral and non-redundant. Am I correct in that using local disk on any VPS has durability concerns?

Yes, it’s the ephemerality that’s the biggest issue. Enterprise-grade SSDs are quite reliable, and typically have PLP so even in the event of a sudden power loss, any queued writes that the drive has accepted - and thus ack’d the fsync() - will be written. Presumably you’d be running some kind of redundancy, likely some flavor of RAID or zRAID (assuming purely local storage here, not a distributed system like Ceph, n…

Agreed on these trade offs. We do both synchronous and semi-synchronous depending on Postgres or MySQL.

Re: Benchmarking Postgres 17 vs. 18

#50

Post by anarazel »

DicIfTEx wrote: post #12

I was expecting `pg_dumpall` to get the `--format` option in v18,[0] but at the moment the docs say it's still only available in the development branch.[1] Is anyone familiar with Postgres development able to give an update on the state of the feature? Is it planned for a future (18 or 19) release? [0]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit... [1]: https://www.postgresql.org/docs/devel/app-pgdu…

The docs for 18 also show it, where do you get from that it's not available for 18?
Post reply on HN