Re: extensible external toast tuple support
От | Andres Freund |
---|---|
Тема | Re: extensible external toast tuple support |
Дата | |
Msg-id | 20130614230625.GD19641@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: extensible external toast tuple support (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: extensible external toast tuple support
Re: extensible external toast tuple support |
Список | pgsql-hackers |
On 2013-05-31 23:42:51 -0400, Robert Haas wrote: > On Thu, May 30, 2013 at 7:42 AM, Andres Freund <andres@2ndquadrant.com> wrote: > > In > > http://archives.postgresql.org/message-id/20130216164231.GA15069%40awork2.anarazel.de > > I presented the need for 'indirect' toast tuples which point into memory > > instead of a toast table. In the comments to that proposal, off-list and > > in-person talks the wish to make that a more general concept has > > been voiced. > > > > The previous patch used varattrib_1b_e.va_len_1be to discern between > > different types of external tuples. That obviously only works if the > > data sizes of all possibly stored datum types are distinct which isn't > > nice. So what the newer patch now does is to rename that field into > > 'va_tag' and decide based on that what kind of Datum we have. To get the > > actual length of that datum there now is a VARTAG_SIZE() macro which > > maps the tags back to size. > > To keep on-disk compatibility the size of an external toast tuple > > containing a varatt_external is used as its tag value. > > > > This should allow for fairly easy development of a new compression > > scheme for out-of-line toast tuples. It will *not* work for compressed > > inline tuples (i.e. VARATT_4B_C). I am not convinced that that is a > > problem or that if it is, that it cannot be solved separately. > > > > FWIW, in some quick microbenchmarks I couldn't find any performance > > difference due to the slightly more complex size computation which I do > > *not* find surprising. > > > > Opinions? > > Seems pretty sensible to me. The patch is obviously WIP but the > direction seems fine to me. Here's the updated version. It shouldn't contain any obvious WIP pieces anymore, although I think it needs some more documentation. I am just not sure where to add it yet, postgres.h seems like a bad place :/ Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: