On Tue, Oct 19, 2010 at 12:28 PM, Greg Smith <greg@xxxxxxxxxxxxxxx> wrote: > Jon Nelson wrote: >> >> That's a little harsh (it's not untrue, though). >> > > Welcome to pgsql-performance! You can get a right answer, or a nice answer, > but given the personalities involved it's hard to get both at the same time. > With this crowd, you need to be careful stating something you were > speculating about as if you were certain of it, and to be certain here > usually means "I read the source code". I recommend writing theories as a > question ("would X have sped this up?") rather than a statement ("X will > speed this up") if you want to see gentler answers. > >> Has any work been done on making use of shared memory for file stats >> or using fallocate (or posix_fallocate) to allocate files in larger >> chunks? >> > > Just plain old pre-allocating in larger chunks turns out to work well. Am > hoping to get that into an official patch eventually. hm...wouldn't larger allocation blocks reduce the frequency of 'this file got larger via another backend' type events, and therefore raise the benefit of pushing the events out vs checking them over and over? merlin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance