On Sun, 4 Jan 1998, Bruce Momjian wrote:
> > No, don't make it a run-time or auto-detect thing, just a compile time
> > option. By default, leave it at 8192, since "that's the way its always been"...
> > but if we are justifying it based on disk block size, its 2x the disk block
> > size that my system is setup for. What's the difference between that and making
> > it 3x or 4x? Or, hell, would I get a performance increase if I brought it
> > down to 4096, which is what my actually disk block size is?
> >
> > So, what we would really be doing is setting the default to 8192, but give
> > the installer the opportunity (with a caveat that this value should be a multiple
> > of default file system block size for optimal performance) to increase it as they
> > see fit.
>
> I assume you changed the default, becuase the BSD44 default is 8k
> blocks, with 1k fragments.
Good question, I don't know. What does BSDi have it set at? Linux? NetBSD?
I just checked our sys/param.h file under Solaris 2.5.1, and it doesn't
seem to define a DEFAULT, but a MAXSIZE of 8192...oops, newfs defines the default
there for 8192 also
> I don't think there is any 'performance' improvement with making it
> greater than the file system block size.
No no...you missed the point. If we are saying that max tuple size is 8k
because of block size of the file system, under FreeBSD, the tuple size is 2x
the block size of the file system. So, if there a performance decrease because
of that...on modern OSs, how much does that even matter anymore? The 8192 that
we have current set, that's probably still from the original Postgres4.2 system
that was written in which decade? :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org