Re: [HACKERS] varchar(), text,char() overhead

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

In response to

Browse pgsql-hackers by date

  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