Re: Postgres as In-Memory Database?
| От | Jeff Janes |
|---|---|
| Тема | Re: Postgres as In-Memory Database? |
| Дата | |
| Msg-id | CAMkU=1zZYznh5bq1VBx_u_JSYS1nZB8GFV_w6qcuM-pH8Pjc2g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Postgres as In-Memory Database? (Stefan Keller <sfkeller@gmail.com>) |
| Список | pgsql-general |
On Sun, Nov 17, 2013 at 1:33 PM, Stefan Keller <sfkeller@gmail.com> wrote:
Hi Edson,On 2013/11/17 Edson Richter <edsonrichter@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
В списке pgsql-general по дате отправления: