From: | Stefan Keller <sfkeller(at)gmail(dot)com> |
---|---|
To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
Cc: | postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: PG as in-memory db? How to warm up and re-populate buffers? How to read in all tuples into memory? |
Date: | 2012-02-28 23:46:40 |
Message-ID: | CAFcOn2-b2ZAi-Zy7v29sqfL+4s5mp8Zpnq1UpHoORQ7ctikNTA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2012/2/28 Claudio Freire <klaussfreire(at)gmail(dot)com>:
> On Tue, Feb 28, 2012 at 5:48 PM, Stefan Keller <sfkeller(at)gmail(dot)com> wrote:
>> P.S. And yes, the database is aka 'read-only' and truncated and
>> re-populated from scratch every night. fsync is off so I don't care
>> about ACID. After the indexes on name, hstore and geometry are
>> generated I do a VACUUM FULL FREEZE. The current installation is a
>> virtual machine with 4GB memory and the filesystem is "read/write".
>> The future machine will be a pizza box with 72GB memory.
>
> I don't get this. Something's wrong.
>
> In the OP, you say "There is enough main memory to hold all table
> contents.". I'm assuming, there you refer to your current system, with
> 4GB memory.
Sorry for the confusion: I'm doing these tests on this machine with
one table (osm_point) and one country. This table has a size of 2.6GB
and 10 million tuples. The other machine has to deal with at least 5
tables in total and will be hold more than one country plus routing
etc..
-Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Flower | 2012-02-29 05:31:29 | Re: Very long deletion time on a 200 GB database |
Previous Message | Claudio Freire | 2012-02-28 23:43:37 | Re: problems with set_config, work_mem, maintenance_work_mem, and sorting |