> One question: would you please expand your answer and explain how would this adversely affect async replication?
Is this a question or a hint (or both) :-)? Of course almost all non-durable settings [1] will delay replication.
I think I have to add, that pure speed of a read-mostly database is the main scenario I have in mind.
Duration, High-availability and Scaling out are perhaps additional or separate scenarios.
I think the main bottleneck you will run into is the client-server architecture. PostgreSQL does not have embedded mode, so every interaction has to bounce data back and forth between processes.
So, to come back to my question: I think that Postgres could be even faster by magnitudes, if the assumption of writing to slow secondary storage (like disks) is removed (or replaced).
I rather doubt that. All the bottlenecks I know about for well cached read-only workloads are around locking for in-memory concurrency protection, and have little or nothing to do with secondary storage.