Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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).


In response to

pgsql-hackers by date

Next:From: Peter T MountDate: 1998-01-22 06:35:20
Subject: Re: [HACKERS] Current open 6.3 issues
Previous:From: Bruce MomjianDate: 1998-01-22 03:08:10
Subject: Current open 6.3 issues

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group