2013/11/18 Andreas Brandl <ml@xxxxxxxxxxxxxx> wrote:
> What is your use-case?
It's geospatial data from OpenStreetMap stored in a schema optimized for PostGIS extension (produced by osm2pgsql).
BTW: Having said (to Martijn) that using Postgres is probably more efficient, than programming an in-memory database in a decent language: OpenStreetMap has a very, very large Node table which is heavily used by other tables (like ways) - and becomes rather slow in Postgres. Since it's of fixed length I'm looking at file_fixed_length_record_fdw extension [1][2] (which is in-memory) to get the best of both worlds.
--Stefan
2013/11/18 Andreas Brandl <ml@xxxxxxxxxxxxxx>
Hi Stefan,
we've put the data directory on our buildserver directly on a ramdisk (e.g. /dev/shm) to improve build times.
> How can Postgres be used and configured as an In-Memory Database?
>
Obviously you then don't care too much about durability here, so one can switch off all related settings (as has already been pointed out). The only thing to do on a server reboot would be to re-create a fresh data directory on the ramdisk.
So if you're able to start from scratch relatively cheap (i.e. on a server reboot), don't care about durability/crash safety at all and your database fits into ram that solution is easy to handle.
I've also tried having only a separate tablespace on ramdisk but abandoned the idea because postgres seemed too surprised to see the tablespace empty after a reboot (all tables gone).
Overall the above solution works and improves our build times but I think there are better ways to have in-memory/application caches than using a postgres.
What is your use-case?
Regards
Andreas
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
