From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Jan Wieck <wieck(at)debis(dot)com>, PostgreSQL HACKERS <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] LONG |
Date: | 1999-12-11 18:13:15 |
Message-ID: | 24017.944935995@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-12-11 18:22:03 | Re: [HACKERS] Re: Mirroring a DB |
Previous Message | Tom Lane | 1999-12-11 17:58:44 | Re: [HACKERS] Re: [PATCHES] pg_dump primary keys |