Re: [PERFORM] Tablespaces on a raid configuration
On Fri, Mar 30, 2012 at 9:32 PM, Tomas Vondra t...@fuzzy.cz wrote: And it's not just about fsync operations - WAL is written in sequential manner. By placing it on the same device as data files you're effectively forcing it to be written randomly, because the the database has to write a WAL record, seeks somewhere else to read something, etc. Or, if you put WAL on a journalled FS, even if it's on dedicated spindles ;-) a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] database slowdown while a lot of inserts occur
Tomas, You are correct. I was assuming that each insert was issued as an implicit transaction, without the benefit of an explicit BEGIN/COMMIT batching many of them together, as I've seen countless times in tight loops trying to pose as a batch insert. Bob From: Tomas Vondra t...@fuzzy.cz To: pgsql-performance@postgresql.org Sent: Friday, March 30, 2012 8:11 PM Subject: Re: [PERFORM] database slowdown while a lot of inserts occur On 29.3.2012 21:27, Bob Lunney wrote: Lance, May small inserts cause frequent fsyncs. Is there any way those small inserts can be batched into some larger sets of inserts that use copy to perform the load? Not necessarily - fsync happens at COMMIT time, not when the INSERT is performed (unless each INSERT stands on it's own). Tomas -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
