On Thu, May 30, 2013 at 7:42 AM, Andres Freund <and...@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
