Live data from Hacker News

Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O

pganalyze.com

131–140 of 159 posts

Re: Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O

#131

Earlier quoted context omitted.

I recently started a ML project using text data and the choice was between MySQL and Postgres. Having looked at the respective features and pros and cons, the choice was immediately obvious. Also, with pgvector and https://postgresml.com available, the choice for Postgres was even easier.

Why not MongoDB?

Because it's web scale...

Re: Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O

#132
post #24

Does anyone know when the update allowing more concurrent connections is dropping, so we can stop using pgbouncer?

That'll likely need conversion from process per connection, so not any time soon

FWIW, there actually are some ongoing efforts towards that - including several preparatory changes in PG 18. Still lots more work, but we are working towards it.

https://wiki.postgresql.org/wiki/Multithreading

Re: Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O

#133
post #89
post #14

Earlier quoted context omitted.

I would absolutely use another backup utility (additionally if you want) if I were you (barman, pgbackrest, etc). You are just wrapping pgdump, which is not a full featured backup solution. Great for a snapshot... Use some of the existing tools and you get point-in-time recovery, easy restores to hot standbys for replication, a good failover story, backup rotations, etc.

do you still need it? haven't managed pg for a while, but shouldn't pg17 have some solution for backups?

You still need it. There are tools included with Postgres that you can cobble together for a backup solution that is lacking in features and edge case testing. But i'd much rather just use the right tool for the job.

For example, pgBackRest solves real problems with features like block level incremental backups that drastically reduce storage and transfer times for many workloads, automated backup retention policies, multiple repository support for offsite backup redundancy, encryption support, point in time recovery for granular restoration capabilities, and tooling to build standby servers very quickly and efficiently. These features handle edge cases and reduce operational overhead compared to managing scripts around pg_basebackup and WAL archiving yourself. In many environments, those features are required (e.g. encryption).

Re: Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O

#134
post #98

Earlier quoted context omitted.

> if I boot with clearcpuid=smap (not for prod use!), larger reads go significantly faster. On both Intel and AMD CPUs interestingly. Is there a page anywhere that collects these sorts of "turn the whole hardware security layer off" switches that can be flipped to get better throughput out of modern x86 CPUs, when your system has no real attack surface to speak of (e.g. air-gapped single-tenant HPC)?

On the kernel side there's a boot parameter for all of them: mitigations=off Software that was compiled with additional fences may have to be recompiled to remove them. https://www.kernel.org/doc/html/latest/admin-guide/kernel-pa...

mitigations=off disables workarounds for bugs or "mis-features" in the CPU that could be exploited to bypass OS security measures.

smap is an OS security measure, and so does not get disabled by mitigations=off. smap can be pretty draining for certain IO performance though. IMO it should be more well-known or covered by a more obvious option.

Linux kernel developers are really bad at defining and naming options like this.

Re: Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O

#135
post #67

I sort of had to chuckle at the 20k IOPS AWS instance, given even a consumer $100-200 NVMe gives ~1million+ IOPS these days. I suspect now we have PCIe 5.0 NVMes this will go up to I always do wonder how much "arbitrary" cloud limits on things like this cause so many issues. I'm sure that async IO is very helpful anyway, but I bet on a 1million IOPS NVMe it is nowhere near as important. We're effectively optimising c…

I noticed this with bandwidth. AWS price for bandwidth: $90.00/TB after 0.1TB/month. Price everywhere else (low cost VPSes): $1.50/TB after 1-5TB/month. Price some places (dedicated servers): $0.00/TB up to ~100TB/month, $1.50/TB after. You pay 60 times the price for the privilege of being on AWS. Bandwidth is just their most egregious price difference. The servers are more expensive too. The storage is more expensiv…

Which is why most folks use CloudFront like AWS recommends, which is typically free for services to route through. Prices for CloudFront egress are competitive with what you described for other vendors. I don't know anyone paying $90/TB out to internet on AWS.

https://aws.amazon.com/cloudfront/pricing/?nc=sn&loc=3

Were you trying to route S3 directly out to the internet?

Re: Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O

#136
post #25

Earlier quoted context omitted.

Maybe they are. With NVMe hat, you get decent IO performance

It's still moderately bad. Raspberry pi is limited to 2 gen3 pcie lanes which is ~4-8x slower than the drive (and you will likely be further limited by cpu speed)

If the engineering demand is lower than the engineering supply, you're still winning. If your transactions per second only amounts to 60% of the Pi's capacity for a given use case, why complain?

Re: Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O

#137
post #59

Are there good performance comparisons between postgres, mariadb and percona? I'm really curious at this point in which case each of those database shine.

Apples to apples, Postgres might lose, but that'd be tying both hands behind its back first.

Remember that Postgres's feature set is far larger than those alternatives. If you can use a range with an exclusion constraint, an unnest with an array, or the like, you'll be seeing Postgres leave the alternatives in the dust.

Imagine writing a benchmark comparing programming languages, but the benchmark only includes idioms that all tested languages shared in common. Wouldn't be a fair comparison, would it?

Re: Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O

#138
post #128

Earlier quoted context omitted.

Why not MongoDB?

The question should be the other way around: why mongodb? It’s not ACID compliant so has major down sides…

According to mongodb it is acid compliant.

https://www.mongodb.com/resources/products/capabilities/acid...

Re: Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O

#139
post #137
post #59

Are there good performance comparisons between postgres, mariadb and percona? I'm really curious at this point in which case each of those database shine.

Apples to apples, Postgres might lose, but that'd be tying both hands behind its back first. Remember that Postgres's feature set is far larger than those alternatives. If you can use a range with an exclusion constraint, an unnest with an array, or the like, you'll be seeing Postgres leave the alternatives in the dust. Imagine writing a benchmark comparing programming languages, but the benchmark only includes idiom…

Yes, but I wonder how many apps using ORMs actually use all features from postgres. So, in the practical use case of typical Rails, Laravel, Django or expressJS, what would the performance look like?

Re: Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O

#140
post #73

Earlier quoted context omitted.

PostgreSQL uses heap files for the primary table storage, not B-trees. In PostgreSQL table data is primarily stored in heap files (unordered collections of pages/blocks). Indexes (including primary key indexes) use B-trees (specifically B+ trees). When you query a table via an index, the B-tree index points to locations in the heap file InnoDB uses a clustered index approach. The primary key index is a B-tree. The ac…

Indexes that point directly to the disk column are also significantly faster to access; it is a persistent pain point for OLAP on InnoDB that all secondary indexes are indirect. You can work around it by adding additional columns to the index to make your lookups covering, but it's kludgy and imprecise and tends to bloat the index even further. (The flip side is that if you have tons of indexes, and update some unrel…

On commercial databases from Oracle and Microsoft, you can cluster the DB on any index. Really would love for Postresql to do the same.
Post reply on HN