Re: Postgres as In-Memory Database?

From: Stefan Keller <sfkeller(at)gmail(dot)com>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Stefan Keller <sfkeller(at)gmail(dot)com>, Edson Richter <edsonrichter(at)hotmail(dot)com>, pgsql-general List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Postgres as In-Memory Database?
Date: 2013-11-17 23:53:38
Message-ID: CAFcOn29kGyQ01VUiraisaAnZ_awuRHTcheLcUgG6g-skiqTEnw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Martijn

2013/11/17 Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:

> > If your dataset fits in memory then the problem is trivial: any decent
> programming language provides you with all the necessary tools to deal
> with data purely in memory.

What about Atomicity, Concurrency and about SQL query language and the
extension mechanisms of Postgres? To me, that's not trivial.

> There are also quite a lot of databases that cover this area.

Agreed. That's what partially triggered my question, It's notably Oracle
TimesTen, MS SQL Server 2014 (project Hekaton), (distributed) "MySQL
Cluster", SAP HANA or SQLite >3. To me this rather confirms that an
architecture and/or configuration for in-memory could be an issue also in
Postgres.

The actual architecture of Postgres assumes that memory resources are
expensive and optimizes avoiding disk I/O. Having more memory available
affects database design e.g. that it can optimize for a working set to be
stored entirely in main memory.

--Stefan

2013/11/17 Martijn van Oosterhout <kleptog(at)svana(dot)org>

> On Sun, Nov 17, 2013 at 10:33:30PM +0100, Stefan Keller wrote:
> > 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.
> >
> > 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).
>
> If your dataset fits in memory then the problem is trivial: any decent
> programming language provides you with all the necessary tools to deal
> with data purely in memory. There are also quite a lot of databases
> that cover this area.
>
> PostgreSQL excels in the area where your data is much larger than your
> memory. This is a much more difficult problem and I think one worth
> focussing on. Pure in memory databases are just not as interesting.
>
> Have a nice day,
> --
> Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> > He who writes carelessly confesses thereby at the very outset that he
> does
> > not attach much importance to his own thoughts.
> -- Arthur Schopenhauer
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIVAwUBUolDw0vt++dL5i1EAQiArQ//cDQUz9YGOC+dmHBjsix1w1DdM3VUpAzE
> U4yWcVb83tsq+jEuY4+NAGTnPk7Ks4cXACNQiMuS5ISSKdxkuCabt+pi1mHwi2z6
> aO8/Fhy4nBIC9qllqCXUpexNrDoarQ3xCSrJF+8AB7Y2dtIpQkEmPszYoF2LzWv+
> vOoydD19xiAVAYAlR+AJi7IBl4Z7IH4ODfdoQ75JW7ZJIjlg8BwPU0wfg8oJbzxT
> nVZMj+8txD6ozzR49yTVXnDXwzlSxG95Bu15uinvBWHHQSuONvvpAhL/IfI1tPH7
> 7pz8KR6+SvFPS5MdsCQ31qSxQThWDg1JkG6aNpch8pG7XI0yBX4uK3ViwM07nIZ9
> hTuEOZvtWwxA1OipwFxxc784qESunnY3zQ293xIaKlVAYG7f8Eg43wjQXL4Pi2Q/
> cXvbh6T3bKQyyEcuStjzGALOXWCM+76P6vk9UhWNx1Gwf2R08MlkcbgwSIxg4CVi
> 7t0jm13/lMYGPpykUb5D1uFoymVOIOBzfpLkgzYcDcpMUjwpDmJhjaPTBwytil0e
> Wh1LzILUC1e+8ojVbh4jY0W/yHdzFVm95zDKdfrLPUigsCte7nCAoC423iblI2VW
> GBFJxydK73ttE1o2wBIK5h6j3vn2e7Tb521vi4eR+lTkjavHtVB6m6Mow+ZFvjvi
> QS4G2eUy9o0=
> =BGV+
> -----END PGP SIGNATURE-----
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stefan Keller 2013-11-18 00:02:15 Re: Postgres as In-Memory Database?
Previous Message Andreas Brandl 2013-11-17 23:14:46 Re: Postgres as In-Memory Database?