RE: [HACKERS] LONG

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Jan Wieck" <wieck(at)debis(dot)com>
Cc: <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgreSQL(dot)org>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: RE: [HACKERS] LONG
Date: 1999-12-13 03:56:08
Message-ID: 005401bf451d$fcc99260$2801007e@cadzone.tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Jan Wieck
>
> >
> > Having a separate oid for the long value is great. You can then have
> > multiple versions of the long attribute in the long table and can
> > control when updating a tuple.
> >
> > I liked Hiroshi's idea of allowing long values in an index by just
> > pointing to the long table. Seems that would work too. varlena access
> > routines make that possible.
>
> Maybe possible, but not that good IMHO. Would cause another
> index scan from inside index scan to get at the value. An we
> all agree that indexing huge values isn't that a good thing
> at all.
>

What I need is an unqiue index (rowid,rowattno,chunk_seq) on
"secondary" table.
Is it different from your orginal idea ?
I don't need any index on primary table.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1999-12-13 03:58:00 update_pg_pwd
Previous Message Tom Lane 1999-12-13 03:31:44 Re: [HACKERS] generic LONG VARLENA