Re: Postgres as In-Memory Database?
| От | Stefan Keller |
|---|---|
| Тема | Re: Postgres as In-Memory Database? |
| Дата | |
| Msg-id | CAFcOn29kGyQ01VUiraisaAnZ_awuRHTcheLcUgG6g-skiqTEnw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Postgres as In-Memory Database? (Martijn van Oosterhout <kleptog@svana.org>) |
| Ответы |
Re: Postgres as In-Memory Database?
(Gavin Flower <GavinFlower@archidevsys.co.nz>)
|
| Список | pgsql-general |
Hi Martijn
2013/11/17 Martijn van Oosterhout <kleptog@svana.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.
> 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@svana.org>
On Sun, Nov 17, 2013 at 10:33:30PM +0100, Stefan Keller wrote:If your dataset fits in memory then the problem is trivial: any decent
> 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).
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@svana.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-----
В списке pgsql-general по дате отправления: