I don't believe it's a performance issue, I believe it's that writes to
blocks greater than 8k cannot be guaranteed 'atomic' by the operating
system. Hence, 32k blocks would break the transactions system. (Or
something like that - am I correct?)
> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org]On Behalf Of Mitch Vincent
> Sent: Tuesday, November 28, 2000 8:40 AM
> To: mlw; Hackers List
> Subject: Re: [HACKERS] 8192 BLCKSZ ?
> I've been using a 32k BLCKSZ for months now without any trouble,
> though I've
> not benchmarked it to see if it's any faster than one with a
> BLCKSZ of 8k..
> > This is just a curiosity.
> > Why is the default postgres block size 8192? These days, with caching
> > file systems, high speed DMA disks, hundreds of megabytes of RAM, maybe
> > even gigabytes. Surely, 8K is inefficient.
> > Has anyone done any tests to see if a default 32K block would provide a
> > better overall performance? 8K seems so small, and 32K looks to be where
> > most x86 operating systems seem to have a sweet spot.
> > If someone has the answer off the top of their head, and I'm just being
> > stupid, let me have it. However, I have needed to up the block size to
> > 32K for a text management system and have seen no performance problems.
> > (It has not been a scientific experiment, admittedly.)
> > This isn't a rant, but my gut tells me that a 32k block size as default
> > would be better, and that smaller deployments should adjust down as
> > needed.
In response to
pgsql-hackers by date
|Next:||From: Lamar Owen||Date: 2000-11-28 01:21:55|
|Subject: Re: full text indexing|
|Previous:||From: John Huttley||Date: 2000-11-28 01:08:00|
|Subject: full text indexing|