Re: [HACKERS] LONG - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] LONG
Date
Msg-id 24017.944935995@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] LONG  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: [PATCHES] pg_dump primary keys
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: Mirroring a DB