Block Sizes
Oracle has adjustable disk block sizes, tuneable per instance
(can you change it after install?? can't remember). In any
case the default is 2k or 4k, and things almost always go
faster with larger block sizes. On one project we needed to
go fast and had disk space to burn, so we upped it to 16k.
This was all _without_ using raw devices.
My *gut* feeling is that the underlying block size is a trade-off,
smaller blocks are better for small transactions, bigger blocks
are better for bulk load/extract operations, with a penalty for
finding a single row. Optimum depends on the application, but is
somewhere between 2 and 32 k.
How hard would it be for postgresql to support adjustable block sizes?
Just wondering.
-- cary
cobrien@access.digex.net
How hard would it be for postgresql to support adjustable block sizes?
Just wondering.
I can take a stab at this tonite after work now that the snapshot is there.
Still have around some of the files/diffs from looking at this a year ago...
I don't think it will be hard, just a few files with BLCKSZ/MAXBLCKSZ
references to check for breakage. Appears that only one bit of lp_flags is
being used too, so that would seem to allow up to 32k blocks.
Other issue is the bit alignment in the ItemIdData structure. In the past,
I've read that bit operations were slower than int ops. Is this the case?
I want to check to see if the structure is only 32 bits and not being padded
by the compiler. Worse to worse, make one field of 32 bits and make macros
to access the three pieces or make lp_off & lp_len shorts and lp_flags a char.
I can check the aix compiler, but what does gcc and other compilers do with
bit field alignment?
darrenk
Import Notes
Resolved by subject fallback
How hard would it be for postgresql to support adjustable block sizes?
Just wondering.I can take a stab at this tonite after work now that the snapshot is there.
Still have around some of the files/diffs from looking at this a year ago...I don't think it will be hard, just a few files with BLCKSZ/MAXBLCKSZ
references to check for breakage. Appears that only one bit of lp_flags is
being used too, so that would seem to allow up to 32k blocks.Other issue is the bit alignment in the ItemIdData structure. In the past,
I've read that bit operations were slower than int ops. Is this the case?
Usually, yes.
I want to check to see if the structure is only 32 bits and not being padded
by the compiler. Worse to worse, make one field of 32 bits and make macros
to access the three pieces or make lp_off & lp_len shorts and lp_flags a char.I can check the aix compiler, but what does gcc and other compilers do with
bit field alignment?
I don't know.
--
Bruce Momjian
maillist@candle.pha.pa.us