Re: [HACKERS] Disk block size issues.
От | darrenk@insightdist.com (Darren King) |
---|---|
Тема | Re: [HACKERS] Disk block size issues. |
Дата | |
Msg-id | 9801091543.AA42140@ceodev обсуждение исходный текст |
Ответы |
Re: [HACKERS] Disk block size issues.
Re: [HACKERS] Disk block size issues. |
Список | pgsql-hackers |
> > A few things that I have noticed will be affected by allowing the > > disk block size to be other than 8k. (4k, 8k, 16k or 32k) > > > > 1. Rules > > > > The rule system currently stores plans as tuples in pg_rewrite. > > Making the block size smaller will accordingly reduce the size of > > the rules you can create. > > I say make it match the given block size at compile time. For now it does. There's a comment in rewriteDefine.c though that indicates the original pg coders thought about putting the stored plans into large objects if 8k was too limiting. Could be nice to have the type limits stored in a system table so the user or a program could query the limits of the current db. > > 2. Attribute limits > > > > Should the size limits of the varchar/char be driven by the chosen > > block size? > > Yes, they should be calculated based on the compile block size. > ... > Just make the max size based on the block size. > ... > This is an interesting point. While we can compute most of the changes > at compile time, we will have to communicate with clients that were > compiled with different max limits. > > I recommend we increase the max client buffer size to what we believe is > the largest block size anyone would ever reasonably choose. That way, > all can communicate. I recommend you contact Peter Mount for JDBC, > Openlink for ODBC, and all the other client maintainers and let them > know the changes will be in 6.3 so they can be ready with new version > when 6.3 starts beta on February 1. So the buffer size will be defined in one place also that they should all reference when compiling or running? In include/config.h I assume? This could be difficult for the ODBC and JDBC drivers to determine automagically since they are usually compiled on different systems that the postgres src. Other stuff... Could the block size be made into a command line option, like "-k 8192"? Would only require that the BLCKSZ define become a variable and that it be passed to the backends too. Much easier than having to recompile/install postgres to change the block size. Could have multiple postmasters running different block-sized databases without having to have a binary around for each size. Renaming BLCKSZ... How about PG_BLOCK_SIZE? Or if it's made a variable, DiskBlockSize, keeping it in the tradition of SortMem, ShowStats, etc. darrenk
В списке pgsql-hackers по дате отправления: