From: | "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | darrenk(at)insightdist(dot)com, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] varchar(), text,char() overhead |
Date: | 1998-01-22 03:47:58 |
Message-ID: | 34C6C16E.985FF25C@sable.krasnoyarsk.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
>
> > > I had forgotten about your mention of this. I am running some tests
> > > now, and things look promising. However, if we go to 64k or 128k
> > > tuples, we would be in trouble. (We can do 64k tuples by changing the
> > ^^^^^^^^^^^^^^^^^^^^^^
> > Also, multi-representation feature allows to have 2Gb in varlena fields.
>
> What is multi-representation feature? Large objects?
Yes. Server could store varlena fields in LO when size of field or
tuple at whole is too big to be stored in relation blocks.
This allows to have tuples much longer than data blocks.
This is also Ok for performance sometime (if big varlenas are not used
in WHERE they could be not read from disk for each tuple; if UPDATE don't
change out-stored varlenas they could be not stored twice).
We could use vl_len < 0 for out-stored varlenas: vl_len = -1000
could mean that size of data is 1000 bytes, data stored in LO and
LO' id (oid?) is in vl_dat. It seems easy to implement (without
optimization of access to data).
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Peter T Mount | 1998-01-22 06:35:20 | Re: [HACKERS] Current open 6.3 issues |
Previous Message | Bruce Momjian | 1998-01-22 03:08:10 | Current open 6.3 issues |