Re: [HACKERS] LONG
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] LONG |
Дата | |
Msg-id | 24017.944935995@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] LONG (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
>> I thought about the huge size variable text type a little >> more. And I think I could get the following implementation >> to work reliable for our upcoming release. >> >> For any relation, having one or more LONG data type >> attributes, another relation (named pg_<something>) is >> created, accessible only to superusers (and internal access >> routines). All LONG data items are stored as a reference >> into that relation, split up automatically so the chunks fit >> into the installation specific tuple limit size. Items are >> added/updated/removed totally transparent. > Should we use large objects for this, and beef them up. Seems that > would be a good way. Yes, I think what Jan is describing *is* a large object, with the slight change that he wants to put multiple objects into the same behind-the-scenes relation. (That'd be a good change for regular large objects as well ... it'd cut down the umpteen-thousand-files problem.) The two principal tricky areas would be (1) synchronization --- having one hidden relation per primary relation might solve the problems there, but I'm not sure about it; and (2) VACUUM. But I don't really see why this would be either easier to do or more reliable than storing multiple segments of a tuple in the primary relation itself. And I don't much care for institutionalizing a hack like a special "LONG" datatype. regards, tom lane
В списке pgsql-hackers по дате отправления: