Re: [HACKERS] include/config.h FOLLOWUP - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: [HACKERS] include/config.h FOLLOWUP
Date
Msg-id Pine.NEB.3.96.980104140820.235Z-100000@thelab.hub.org
Whole thread Raw
In response to Re: [HACKERS] include/config.h FOLLOWUP  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] include/config.h FOLLOWUP  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
On Sun, 4 Jan 1998, Bruce Momjian wrote:

> Yes, you certainly could do that.  The comment says:
>
>     /*
>      * the maximum size of a disk block for any possible installation.
>      *
>      * in theory this could be anything, but in practice this is actually
>      * limited to 2^13 bytes because we have limited ItemIdData.lp_off and
>      * ItemIdData.lp_len to 13 bits (see itemid.h).
>      */
>     #define MAXBLCKSZ       8192
>
> You can now specify the actual file system block size at the time of
> newfs.  We actually could query the file system at time of compile, but
> that would be strange becuase the database location is set at time of
> postmaster startup, and I don't think we can make this a run-time
> parameter, but I may be wrong.

    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.

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] include/config.h FOLLOWUP
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] include/config.h FOLLOWUP