Re: [PATCH] Extending pg_class info + more flexible TOAST chunk size

ITAGAKI Takahiro napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> wrote:
> 
>> Bacause MAX_TOAST_CHUNK_SIZE is related on page layout version I need have toast 
>> chunk size more flexible.
> 
> I agree that flexible toast threshold is useful, but I have
> several questions in your implementations.
> 
>> 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.
> 
> We need many infrastructural changes for making it work:
> 
>   1. Change BLCKSZ to be a variable from a constant value.
>      It allows us to have "initdb --blocksize=16kB".
>   2. Make bufmgr handle different sizes of pages in a server instance.
>      I think it is a difficult task.
>   3. Have a SQL interface for 2.
> 
> You suggested only 3, but 1 and 2 are more important.

I know about problem complexity. If you find on how many places BLCKSZ is used 
you get basic picture.

>> 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.
> 
> I'm not sure why relsegsize should be adjusted per-relation basis.
> If there are no limitations in filesystem and in backup
> utilities, large relsegsize is always better, no?
> Is it enough to have "initdb --segsize=4GB" ?

It is related to tablespace. Usually one table space is stored on different 
volume which can have different FS. The question is how to handle relation 
migration from one tablespace to another. In most cases it requires physical 
copy  which could change seg size anyway. Maybe extend pg_tablespace makes more 
sense.

>> relmaxitemsize - it is set to TOAST_MAX_CHUNK_SIZE.
> 
> You added new columns in pg_class, but we have another choice to use
> pg_class.reloptions. What is the reason you choose new-columns-way?

Good point I will look on it.

> Another question is that we should have per-column toast control
> options not only per-relation ones. Do we also need to modify
> pg_attribute in the same way?

Currently we have one TOAST table per heap table (if it contains varlena 
attribute). Data in the TOAST table are stored without any idea what data type 
it is.
Thanks Zdenek

-- 
Zdenek Kotala              Sun Microsystems
Prague, Czech Republic     http://sun.com/postgresql