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.
> 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" ?
> 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?
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?
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
