Re: [HACKERS] varchar(), text,char() overhead
От | darrenk@insightdist.com (Darren King) |
---|---|
Тема | Re: [HACKERS] varchar(), text,char() overhead |
Дата | |
Msg-id | 9801221536.AA28548@ceodev обсуждение исходный текст |
Список | pgsql-hackers |
> > > > I had forgotten about your mention of this. I am running some tests > > now, and things look promising. However, if we go to 64k or 128k > > tuples, we would be in trouble. (We can do 64k tuples by changing the > > 'special variable' length value from -1 to 0. > > > > I am not going to make any changes to the variable length overhead for > char(), varchar(), and text at this time. It is too close to beta. I > will keep the item on the TODO list, and we can hash it out later. > I've been slowed this week...totalled my car Sat. nite (actually some other bonehead did it for me), so I've been a touch busy with insurance agents, etc...but I _will_ have this in by the beta date. Tuples will only go up to 32k since there are only 15 bits available to point to items on the page. Unless we want to expand that structure...I tested bit-field alignment on aix and it seems to favor 4-byte boundaries. For now the three bit fields total 32 bits, but expand those and the size is padded up to 64. I have no idea how gcc or other compilers align bit fields. I been working without trying to expand this structure size, so I've stuck to 32k (15-bits) as the limit. I have so far... 1. Synced all references to the BLCKSZ define. 2. Made a "-k" option to postgres and created a global "BlockSize" variable. 3. Fixed the places where BLCKSZ was used in variable declarations to use the BlockSize global. To do... 1. Should the block size of a database be written to a file like the version? And then be read in when postmaster starts and passed to each backend? This would limit all of the databases in one PG_DATA directory to the same block size. Couldn't do it on a "per database" basis since the template is only created once by initdb. 2. Should the limit of the char fields be based on the block size? Been trying to get this to work. Creates fields just fine, but backend seems to be passing the fields back padded to the full size. Is it possible for the back and front end to have a tuple split across packets or does everything have to be in one 8k packet? Rather than have the interfaces needing to know about differing sizes, could tuples-spanning-packets be added to the libpq protocol somehow? Or would this have a bottleneck effect? darrenk
В списке pgsql-hackers по дате отправления: