Tape files and MAXBLCKSZ vs. BLCKSZ
От | darrenk@insightdist.com (Darren King) |
---|---|
Тема | Tape files and MAXBLCKSZ vs. BLCKSZ |
Дата | |
Msg-id | 9801070052.AA83406@ceodev обсуждение исходный текст |
Ответы |
Re: [HACKERS] Tape files and MAXBLCKSZ vs. BLCKSZ
|
Список | pgsql-hackers |
> 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. I have finished "fixing" the code for this and have a test system of postgres running with 4k blocks right now. Tables appear to take about 10% less space. Simple btree indices are taking the same as with 8k blocks. Regression is running now and is going smoothly. Now for the question... In backend/access/nbtree/nbtsort.c, ---> #define TAPEBLCKSZ (MAXBLCKSZ << 2) So far MAXBLCKSZ has been equal to BLCKSZ. What effect will a MAXBLCKSZ=32768 have on these tape files? Should I leave it as MAXBLCKSZ this big or change them to BLCKSZ to mirror the real block size being used? > I can check the aix compiler, but what does gcc and other compilers do with > bit field alignment? The ibm compiler allocates the ItemIdData as four bytes. My C book says though that the individual compiler is free to align bit fields however it chooses. The bit-fields might not always be packed or allowed to cross integer boundaries. darrenk
В списке pgsql-hackers по дате отправления: