>
> Hrmmm...what does one gain over the other though? The way I saw
> it (sorry Darren, don't mean to oversimplify it), but making the blocksize
> changeable was largely a matter of Darren making sure that all the
> dependencies were covered through the code. What is making a row span
> multiple blocks going to give us? Truly variable length "blocksizes"?
>
> The blocksize patch allows you to stipulate a different blocksize
> at database creation time...actually, thinking about it, I kinda see them
> as to inter-related, yet different, functions. If, for instance, I create
> a table that the majority of tuples are larger then 8k, but smaller then
> 12k, so that most of the tuples, in your "vision", span two
> blocks...wouldn't being able to increase the blocksize to 12k provide a
> performance improvement?
>
> I'm just not sure if I see either/or being mutually exclusive.
> The 'row spanning' is great from the perspective that we didn't expect the
> size of the tuples being larger then 8k, while the increase of blocksize
> being great from an optimizing perspective. Even having vacuum (or
> something similar) reporting that >50% of the records are >$currblocksize
> might be cool...
Most filesystem base block sizes are 8k. Making anything larger is not
going to gain much. I don't think we can support block sizes like 12k
because the filesystem is going to sync stuff in 8k chunks.
Seems like we should do the most user-transparent thing and just allow
spanning rows.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
