Re: Question about todo item - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Question about todo item
Date
Msg-id 6130.996983724@sss.pgh.pa.us
Whole thread Raw
In response to Re: Question about todo item  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Offhand this seems like it would be doable for a column-value that
>> was actually moved out-of-line by TOAST, since the open_toast_object
>> function could see and return the TOAST pointer, and then the read/
>> write operations just hack on rows in pg_largeobject.  The hard part

> I am confused how pg_largeobject is involved?

s/pg_largeobject/toast_table_for_relation/ ... sorry about that ...

> Don't forget compression of TOAST columns.  How do you fseek/read/write
> in there?

Well, you can *do* it, just don't expect it to be fast.  The
implementation would have to read or write most of the value, not just
the segment you wanted.  A person who actually expected to use this
stuff would likely want to disable compression on a column he wanted
random access within.

Hmm ... that provides an idea.  We could easily add some additional
'attstorage' settings that say *all* values of a column must be forced
out-of-line (with or without allowing compression), regardless of size.
Then, open_toast_object would work reliably on such a column.  One
possible user API to such an infrastructure is to invent BLOB and CLOB
datatypes, which are just like bytea and text except that they force the
appropriate attstorage value.  Ugly as sin, ain't it ... but I bet it
could be made to work.

Okay, there's your idea.  Now, who can do better?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Question about todo item
Next
From: Bruce Momjian
Date:
Subject: Idea for nested transactions / savepoints