Re: [HACKERS] LONG

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

Responses

Browse pgsql-hackers by date

  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