| 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: | Whole Thread | Raw Message | 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
| 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 |