Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> 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.
> Isn't the offset-to-compressable-data variable though, depending on the > number of keys, etc? Would we be increasing first_success_by based off > of some function which inspects the object? Given that this is a short-term hack, I'd be satisfied with setting it to INT_MAX. If we got more ambitious, we could consider improving the cutoff logic so that it gives up at "x% of the object or n bytes, whichever comes first"; but I'd want to see some hard evidence that that was useful before adding any more cycles to pglz_compress. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers