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