Re: [HACKERS] varchar(), text,char() overhead

> >
> > 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