Re: [HACKERS] What I'm working on

From: "Stupor Genius" <stuporg(at)erols(dot)com>
To: "Pgsql-Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] What I'm working on
Date: 1998-08-24 02:07:12
Message-ID: 000201bdcf03$e850c1a0$e198accf@darren
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-08-24 02:08:34 Open 6.4 items
Previous Message Bruce Momjian 1998-08-24 02:07:04 Re: [HACKERS] What I'm working on