> > I have been thinking about the blocksize patch, and I now think it is
> > good we never installed it. I think we need to enable rows to span more
> > than one block. That is what commercial databases do, and I think this
> > is a much more general solution to the problem than increasing the block
> > size.
>
> 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"?
Would theoretically remove the postgres maximum size limit on a tuple and
make it limited by the OS file-size limit.
Right now max-tuple-size and blocksize are the same, with the blocksize
being changable only at compile-time. With the outdated patch that I
have, this would change to run-time. Would be less important if chaining
existed, but might be a decent stop-gap feature until then.
I know that Oracle has chaining and they warn that it does have an effect
on performance since a second (or more) tuple fetch has to be done. But
it that's what someone needs for big tuples, that's the price then.
I'll have more opinions after next week.
Darren