On 12 August 2010 21:09, Odd Man <valod...@gmail.com> wrote: > Hi, > > In my current project we have unusual (at least for me) conditions for > relation db, namely: > * high write/read ratio (writes goes from bulk data updates/inserts (every > couple or minutes or so)) > * loosing some recent part of data (last hour for example) is OK, it can be > easy restored > > First version of app that used plain updates worked too long, it was > replaced with version two that uses partitions, truncate, copy and cleanup > of old data once daily. It works reasonably fast with current amount of > data. But this amount will grow, so I'm looking for possible optimisations. > > The main idea (exept using some non relational db) I have is to say postgres > to make more operation in memory and use fsync and other operations less. > For example, I have idea to setup partition in memory, corresponding > tablespace and use it for that data. Main problem here that amount of data > is big and only part is going to be updated realy frequently. > > Are there any ideas, best practies or so in such conditions? >
You can set synchronous_commit to "off". That doesn't wait for data to be written to WAL. -- Thom Brown Registered Linux user: #516935 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
