Thread

Re: [HACKERS] Disk block size issues.

Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-01-09T02:50:54Z

Darren King wrote:
> 
> A few things that I have noticed will be affected by allowing the
> disk block size to be other than 8k. (4k, 8k, 16k or 32k)
> 
> 1. Rules
> 
> The rule system currently stores plans as tuples in pg_rewrite.
> Making the block size smaller will accordingly reduce the size of
> the rules you can create.
> 
> But, the converse is also true...bigger blocks -> bigger rules.
> 
> Are the rules ever going to become large objects?  Is this something
> to put on the TODO to investigate now that Peter has fixed them?

It's better to implement multi-representation feature for all verlena
types. We could use on-disk vl_len < 0 to flag that data of size ABS(vl_len)
are in large object specified in vl_data. It seems very easy to do.

This will also resolve item 2 below.

Vadim

> 
> 2. Attribute limits
> 
> Should the size limits of the varchar/char be driven by the chosen
> block size?
> 
> Since the current max len is 4k, should I for now advise that the
> block size not be made smaller than the current 8k?  Or could the
> limit be dropped from 4096 to 4000 to allow 4k blocks?
> 
> Oracle has a limit of 2000 on their varchar since they allow blocks
> of as little as 2k.
> 
> Seems there would be an inconsistency in there with telling the user
> that the text/varchar/char limit is 4096 and then not letting them
> store a value of that size because of the tuple/block size limit.
> 
> Perhaps mention this as a caveat also if using 4k blocks?  Are 4k
> block something that someone would be beneficial or only 16k/32k?
> 
> On the flip-side of this, uping the max text size though will run
> into the 8k packet size.
> 
> I've run thru the regression tests a few times with 4k blocks and
> they seem to pass with the same differences.  Today I will try with
> 16k and 32k.  If those work, I'll submit the patch for perusal.
> 
> Comments welcome...
> 
> darrenk@insightdist.com