Re: [HACKERS] What I'm working on

>
>     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)