On Mon, Aug 11, 2014 at 3:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> ... I think it would be a better idea to arrange some method by
>> which JSONB (and perhaps other data types) can provide compression
>> hints to pglz.
>
> I agree with that as a long-term goal, but not sure if it's sane to
> push into 9.4.
>
> What we could conceivably do now is (a) add a datatype OID argument to
> toast_compress_datum, and (b) hard-wire the selection of a different
> compression-parameters struct if it's JSONBOID. The actual fix would
> then be to increase the first_success_by field of this alternate struct.
I think it would be perfectly sane to do that for 9.4. It may not be
perfect, but neither is what we have now.
> A longer-term solution would be to make this some sort of type property
> that domains could inherit, like typstorage is already. (Somebody
> suggested dealing with this by adding more typstorage values, but
> I don't find that attractive; typstorage is known in too many places.)
> We'd need some thought about exactly what we want to expose, since
> the specific knobs that pglz_compress has today aren't necessarily
> good for the long term.
What would really be ideal here is if the JSON code could inform the
toast compression code "this many initial bytes are likely
incompressible, just pass them through without trying, and then start
compressing at byte N", where N is the byte following the TOC. But I
don't know that there's a reasonable way to implement that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
