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 по дате отправления: