Re: jsonb format is pessimal for toast compression
От | Robert Haas |
---|---|
Тема | Re: jsonb format is pessimal for toast compression |
Дата | |
Msg-id | CA+TgmoYO1g=dCBz8wXt_h-AM-3y3gRRarGHjPFK3TRmX6GMpqg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: jsonb format is pessimal for toast compression (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: jsonb format is pessimal for toast compression
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: