Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> Bacause MAX_TOAST_CHUNK_SIZE is related on page layout version I need have toast
>> chunk size more flexible.
>
>> Attached patch add three new columns into pg_class
>
>> relblocksize - which is always BLCKSZ. I put it there for fullness, but i could
>> be use in future development to specify different BLCKSZ per relation.
>
>> relsegsize - currently it is always RELSEG_FILE. I performed basic adjustment in
>> smgr.c and md.c. Now only smgropen contains reference to RELSEG_FILE. The
>> problem how to do it fully dynamic is how to pass information rel_rd->relsegsize
>> down into smgropen. One idea is to extend relfilenode, but I'm not sure about it.
>
>> relmaxitemsize - it is set to TOAST_MAX_CHUNK_SIZE. Other relation has this
>> value set to zero for now. toast functions are fully aware about this setting
>> and use it. This column will be convert to int2vector during pg_upgrade
>> development (I need to track information for each page version).
>
> There is not one of these things that we have any intention of being
> allowed to vary on a per-relation basis. Why don't you read them out of
> pg_control?
The problem what I need to solve is how to handle different TOAST chunk size
which becomes with upgrade. if you insert new record into TOAST table it will be
created on the new page which has different max chunk size, because it depends
on page header size. It means that one TOAST table will have more chunk size.
Use old value from previous version is possible but it could invoke waste of
space in situation when pageheader in a new version is bigger.
Another solution is to take first chunk size and say - it is max chunk size.
Relsegsize is related to tablespace but when you upgrade you could want to use
new size for new tables. But it is not important for pg_upgrade project.
Blocksize is more nice to have int this moment, but It makes me sense to have
different block size for toast table and heap. I know that this idea requires
lot of changes including buffer cache and so on.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql