Re: Postgres as In-Memory Database?

On Sun, Nov 17, 2013 at 1:33 PM, Stefan Keller <sfkeller(at)gmail(dot)com> wrote:

> Hi Edson,
>
> On 2013/11/17 Edson Richter <edsonrichter(at)hotmail(dot)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