Re: Postgres as In-Memory Database?
От | Edson Richter |
---|---|
Тема | Re: Postgres as In-Memory Database? |
Дата | |
Msg-id | BLU0-SMTP1254A5DC1A45C82D5143423CFE50@phx.gbl обсуждение исходный текст |
Ответ на | Re: Postgres as In-Memory Database? (Andreas Brandl <ml@3.141592654.de>) |
Список | pgsql-general |
Em 17/11/2013 20:46, Andreas Brandl escreveu: > Edson, > >> Em 17/11/2013 19:26, Stefan Keller escreveu: >>> Hi Edson >>> >>> As Rob wrote: Having a feature like an in-memory table like SQLite >>> has >>> [1] would make application cahces obsoleteand interesting to >>> discuss >>> (but that was'nt exactly what I asked above). >> Hi, Stephan, >> >> I don't think any feature you add to database server would bring >> obsolescence to app server caches: app server caches have just no lag >> at >> all: >> >> 1) Don't need network connection to database server >> 2) Don't need to materialize results (for instance, I have in mind a >> Java or .Net app server running hundred thousands of objects in >> memory). >> >> IMHO, no matter how much you improve database, app server caches >> provides additional level of speed that cannot be achieved by >> database. >> >> That said, I still can see huge improvements in database server. >> Having strong in memory operation would bring substantial >> improvements. >> For instance, if you have in-memory database (tables, indexes, etc) >> for >> all sort of queries, and just **commit** to disks, then you will have >> unprecedent performance. >> I would get benefit from this architecture, since typical customer >> database has < 64Gb on size (after 2 or 3 years of data recording). >> So, >> a database server with 64Gb of memory would keep everything in >> memory, >> and just commit data to disc. >> >> In this case, commited data would be instantly available to queries >> (because they are all in memory) while log (changes) is recorded in a >> fast disk (a SSD, perhaps) and then those changes are made persistent >> data, written async into slow massive disks (SCSI or SAS). >> >> This would allow also a hybrid operation (too keep as much data pages >> as >> possible in memory, with a target of 50% or more in memory). >> >> When database server is started, it would have lazy load (data is >> loaded >> and kept in memory as it is used) or eager load (for slower startup >> but >> faster execution). > not sure I fully understand your point. Isn't this the typical mode-of-operation plus added cache warming? > > Anyways, just wanted to point you to [1] which gives a good overview of cache warming techniques. > > Regards, > Andreas > > [1] http://raghavt.blogspot.fr/2012/04/caching-in-postgresql.html > > Worndeful, never knew about it. I'm ready ASAP. Regards Edson
В списке pgsql-general по дате отправления: