[HACKERS] Max size of data types and tuples. (fwd)
От | Bruce Momjian |
---|---|
Тема | [HACKERS] Max size of data types and tuples. (fwd) |
Дата | |
Msg-id | 199801100308.WAA28501@candle.pha.pa.us обсуждение исходный текст |
Список | pgsql-hackers |
Here's a blast from the past. Shows how I keep those open issues in my mailbox. Forwarded message: > From scrappy@postgreSQL.org Wed Jan 29 14:49:26 1997 > X-Authentication-Warning: hub.org: pgsql set sender to owner-pg95-dev@postgreSQL.org using -f > Date: Wed, 29 Jan 1997 13:38:10 -0500 > From: aixssd!darrenk@abs.net (Darren King) > Message-Id: <9701291838.AA22296@ceodev> > To: hackers@postgreSQL.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@hub.org > Reply-To: hackers@hub.org, aixssd!darrenk@abs.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@insightdist.com > -- Bruce Momjian maillist@candle.pha.pa.us
В списке pgsql-hackers по дате отправления:
Предыдущее
От: darrenk@insightdist.com (Darren King)Дата:
Сообщение: Re: [HACKERS] Disk block size issues.