Re: [HACKERS] LONG

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: wieck(at)debis(dot)com (Jan Wieck)
Cc: pgman(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian), pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] LONG
Date: 1999-12-13 03:23:42
Message-ID: 7598.945055422@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

wieck(at)debis(dot)com (Jan Wieck) writes:
>> 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.

Well, no, you shouldn't make indexes on fields that are usually big.
But it'd be awfully nice if the system could cope with indexing fields
that just had a long value once in a while. Right now, our answer is
to refuse to let you insert a long value into an indexed field; I don't
think that's very satisfactory.

What do you think of my idea of not using any index on the expansion
table at all, but instead having the primary tuple reference the
expansion tuples via their CTIDs? More work at VACUUM time, for sure,
but a lot less work elsewhere.

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-12-13 03:25:54 Re: [HACKERS] LONG
Previous Message Tom Lane 1999-12-13 03:17:51 Re: [HACKERS] generic LONG VARLENA