Thread: Tape files and MAXBLCKSZ vs. BLCKSZ

Tape files and MAXBLCKSZ vs. BLCKSZ

From
darrenk@insightdist.com (Darren King)
Date:
> 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

Re: [HACKERS] Tape files and MAXBLCKSZ vs. BLCKSZ

From
Bruce Momjian
Date:
>
> > 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 would keep it equal to BLCKSZ.  I see no reason to make it different,
unless the btree sorting is expecting to take 2x the block size.  Vadim
may know.


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


--
Bruce Momjian
maillist@candle.pha.pa.us