On Sun, Nov 17, 2013 at 1:33 PM, Stefan Keller <sfkel...@gmail.com> wrote:
> Hi Edson, > > On 2013/11/17 Edson Richter <edsonrich...@hotmail.com> 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
