Re: [HACKERS] LONG
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] LONG |
Дата | |
Msg-id | 199912130238.VAA13410@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] LONG (wieck@debis.com (Jan Wieck)) |
Ответы |
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. 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. -- 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 по дате отправления: