>
> 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? :)
I see, we could increase it and it probably would not matter much.
--
Bruce Momjian
maillist@candle.pha.pa.us