[HACKERS] Max size of data types and tuples. (fwd)

Here's a blast from the past. Shows how I keep those open issues in my
mailbox.

Forwarded message:
> From scrappy(at)postgreSQL(dot)org Wed Jan 29 14:49:26 1997
> X-Authentication-Warning: hub.org: pgsql set sender to owner-pg95-dev(at)postgreSQL(dot)org using -f
> Date: Wed, 29 Jan 1997 13:38:10 -0500
> From: aixssd!darrenk(at)abs(dot)net (Darren King)
> Message-Id: <9701291838(dot)AA22296(at)ceodev>
> To: hackers(at)postgreSQL(dot)org
> Subject: [HACKERS] Max size of data types and tuples.
> Mime-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Content-Md5: 9bBKVeeTrq97EhvkS6qT3A==
> Sender: owner-pg95-dev(at)hub(dot)org
> Reply-To: hackers(at)hub(dot)org, aixssd!darrenk(at)abs(dot)net (Darren King)
>
>
> Does anyone know of a valid reason for the 4096 byte limit
> on the textual fields (char, varchar, text, etc...)?
>
> Could it be bumped to (MAXTUPLEN - sizeof(int)) in the parser
> and in utils/adt/varchar.c? MAXTUPLEN would have to be
> calculated more accurately though as noted in the comment
> around its definition.
>
>
> The following are just some of my observations and comments
> on things that I think should be cleaned up a little in
> the source (and I'll volunteer to do them).
>
> 1. Clean up the #defines for the max block size. Currently,
> there are at least four references to 8192...
>
> include/config.h
> include/storage/bufmgr.h
> include/optimizer/internal.h
> backend/rewrite/rewriteDefine.c
>
> The _PAGE_SIZE_ in internal.h is _not_ used anywhere in the
> optimizer. This define should be linked to BLCKSZ, but would
> be better to remove it and just use BLCKSZ.
>
> optimizer/costsize.c includes storage/bufpage.h for BLCKSZ,
> but in fact this is defined in config.h!. Also included in
>
> executor/nodeHash.c
> executor/nodeHashjoin.c
> utils/sort/psort.c
>
> __These includes of storage/bufpage.h can be removed.__
>
>
> There should be #define MAX_BLOCK_SIZE 8192
> #define CURRENT_BLOCK_SIZE 8192
>
> The MAX_BLOCK_SIZE is a hard and fast limit since only 13 bits
> can be used in offsets and the like. I believe that in the
> future, PostgreSql should support block sizes other than 8k,
> like 2k and 4k. Long-term goal, but the code should be done
> to allow this at a future time. The comments in storage/bufpage.h
> suggest to me that the original designers of Postgres had this
> in mind.
>
>
> 2. Once the block size issue is taken care of, calculate the
> maximum tuple size more accurately.
>
>
> 3. When #1 & #2 are resolved, let the textual fields have a max
> of (MAX_TUPLE_SIZE - sizeof(int)).
>
>
> 4. Since only 13 bits are needed for storing the size of these
> textual fields in a tuple, could PostgreSql use a 16-bit int to
> store it? Currently, the size is padded to four bytes in the
> tuple and this eats space if you have many textual fields.
> Without further digging, I'm assuming that the size is double-word
> aligned so that the actual text starts on a double-word boundary.
>
> Thanks for reading this far. :)
>
> Comments, suggestions most welcome...
>
>
> Darren darrenk(at)insightdist(dot)com
>

--
Bruce Momjian
maillist(at)candle(dot)pha(dot)pa(dot)us