On Sun, Nov 17, 2013 at 1:33 PM, Stefan Keller <sfkeller@xxxxxxxxx> wrote:
Hi Edson,On 2013/11/17 Edson Richter <edsonrichter@xxxxxxxxxxx> you wrote:> 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.
Cheers,
Jeff
