Thread

Re: [HACKERS] include/config.h FOLLOWUP

Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-04T19:39:30Z

> 
> 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