Re: [HACKERS] Storing rows bigger than one block

From: "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su>
To: Mattias Kregert <matti(at)algonet(dot)se>
Cc: Darren King <darrenk(at)insightdist(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Storing rows bigger than one block
Date: 1998-01-13 08:54:09
Message-ID: 34BB2BB1.50AA6127@sable.krasnoyarsk.su
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mattias Kregert wrote:
>
> Darren King wrote:
>
> > There is a var in the tuple header, t_chain, 6.2.1 that has since been
> > removed for 6.3. I think its original purpose was with time-travel,
> > _but_, if we go with a ROWID instead of an oid in the future, this could
> > be put back in the header and would be the actual address of the next
> > block in the chain.

No, this is not for time-travel. Look at implementation guide.

> >
> > Oracle has this concept of chained rows. It is how they implement all
> > of their LONG* types and also handle rows of normal types that are
> > larger than the block size.
>
> Yes! I can't see why PostgreSQL should not be able to store rows bigger
> than one block? I have seen people referring to this limitation every
> now and then, but I don't understand why it has to be that way?
> Is this something fundamental to PostgreSQL?
^^^^^^^^^^^
It seems that answeer is "No". Just - not implemented feature.
Personally, I would like multi-representation feature more than that.
And easy to implement.

Vadim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vadim B. Mikheev 1998-01-13 14:20:25 Re: [HACKERS] Re: subselects
Previous Message Bruce Momjian 1998-01-13 05:42:08 Re: [HACKERS] Re: varchar() troubles (fwd)