ITAGAKI Takahiro napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
