Re: [HACKERS] LONG
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] LONG |
Дата | |
Msg-id | 199912130412.XAA15261@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] LONG (wieck@debis.com (Jan Wieck)) |
Ответы |
RE: [HACKERS] LONG
Re: [HACKERS] LONG |
Список | pgsql-hackers |
> > > > > The solution I see is to give any out of line datum another > > > Oid, that is part of it's header and stamped into the > > > reference data. That way, the long attribute lookup can use > > > SnapshotAny using this Oid, there can only be one that > > > exists, so SnapshotAny is safe here and forces that only the > > > visibility of the master tuple in the main table counts at > > > all. > > > > This is a great idea. Get rid of my use of the attribute number. Make > > the varlena long value be: > > > > long-bit|length|longrelid|longoid|longlen > > > > No need for attno in there anymore. > > I still need it to explicitly remove one long value on > update, while the other one is untouched. Otherwise I would > have to drop all long values for the row together and > reinsert all new ones. I am suggesting the longoid is not the oid of the primary or long* table, but a unque id we assigned just to number all parts of the long* tuple. I thought that's what your oid was for. > > > 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. May as well. I can't think of a better solution for indexing when you have long values. I don't think we want long* versions of indexes. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: