On Sun, 23 Aug 1998, Bruce Momjian wrote:
> [Charset iso-8859-1 unsupported, filtering to ASCII...]
> > > I am working on a patch to:
> > >
> > > remove oidname, oidint2, and oidint4
> > > allow the bootstrap code to create multi-key indexes
> >
> > Good man...always bugged me that the "old" hacked-in multikey
> > indexes were there after Vadim let the user create them.
> >
> > But...returning to Insight as of Sept.1st. Once I get settled
> > in, I should be to stay late a couple of evenings and get my
> > old patches up-to-date.
>
> 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"?
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...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
