Re: [HACKERS] include/config.h FOLLOWUP
От | The Hermit Hacker |
---|---|
Тема | Re: [HACKERS] include/config.h FOLLOWUP |
Дата | |
Msg-id | Pine.NEB.3.96.980104140820.235Z-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] include/config.h FOLLOWUP (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] include/config.h FOLLOWUP
|
Список | 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 по дате отправления: