Re: Question about todo item

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Question about todo item
Дата
Msg-id 6130.996983724@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Question about todo item  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Question about todo item
Следующее
От: Bruce Momjian
Дата:
Сообщение: Idea for nested transactions / savepoints