> > 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.
>
> I say make it match the given block size at compile time.
For now it does. There's a comment in rewriteDefine.c though that
indicates the original pg coders thought about putting the stored
plans into large objects if 8k was too limiting.
Could be nice to have the type limits stored in a system table so
the user or a program could query the limits of the current db.
> > 2. Attribute limits
> >
> > Should the size limits of the varchar/char be driven by the chosen
> > block size?
>
> Yes, they should be calculated based on the compile block size.
> ...
> Just make the max size based on the block size.
> ...
> This is an interesting point. While we can compute most of the changes
> at compile time, we will have to communicate with clients that were
> compiled with different max limits.
>
> I recommend we increase the max client buffer size to what we believe is
> the largest block size anyone would ever reasonably choose. That way,
> all can communicate. I recommend you contact Peter Mount for JDBC,
> Openlink for ODBC, and all the other client maintainers and let them
> know the changes will be in 6.3 so they can be ready with new version
> when 6.3 starts beta on February 1.
So the buffer size will be defined in one place also that they should all
reference when compiling or running? In include/config.h I assume?
This could be difficult for the ODBC and JDBC drivers to determine
automagically since they are usually compiled on different systems that
the postgres src.
Other stuff...
Could the block size be made into a command line option, like "-k 8192"?
Would only require that the BLCKSZ define become a variable and that it
be passed to the backends too. Much easier than having to recompile/install
postgres to change the block size. Could have multiple postmasters running
different block-sized databases without having to have a binary around for
each size.
Renaming BLCKSZ...
How about PG_BLOCK_SIZE? Or if it's made a variable, DiskBlockSize, keeping
it in the tradition of SortMem, ShowStats, etc.
darrenk