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