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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company