Apologies if this is a ridiculous suggestion, but I believe that swapping out the compression algorithm (for Snappy, for example) has been discussed in the past. I wonder if that algorithm is sufficiently different that it would produce a better result, and if that might not be preferable to some of the other options.
On Thu, Aug 7, 2014 at 11:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I looked into the issue reported in bug #11109. The problem appears to be > that jsonb's on-disk format is designed in such a way that the leading > portion of any JSON array or object will be fairly incompressible, because > it consists mostly of a strictly-increasing series of integer offsets. > This interacts poorly with the code in pglz_compress() that gives up if > it's found nothing compressible in the first first_success_by bytes of a > value-to-be-compressed. (first_success_by is 1024 in the default set of > compression parameters.) > > As an example, here's gdb's report of the bitwise representation of the > example JSON value in the bug thread: > > 0x2ab85ac: 0x20000005 0x00000004 0x50003098 0x0000309f > 0x2ab85bc: 0x000030ae 0x000030b8 0x000030cf 0x000030da > 0x2ab85cc: 0x000030df 0x000030ee 0x00003105 0x6b6e756a > 0x2ab85dc: 0x400000de 0x00000034 0x00000068 0x0000009c > 0x2ab85ec: 0x000000d0 0x00000104 0x00000138 0x0000016c > 0x2ab85fc: 0x000001a0 0x000001d4 0x00000208 0x0000023c > 0x2ab860c: 0x00000270 0x000002a4 0x000002d8 0x0000030c > 0x2ab861c: 0x00000340 0x00000374 0x000003a8 0x000003dc > 0x2ab862c: 0x00000410 0x00000444 0x00000478 0x000004ac > 0x2ab863c: 0x000004e0 0x00000514 0x00000548 0x0000057c > 0x2ab864c: 0x000005b0 0x000005e4 0x00000618 0x0000064c > 0x2ab865c: 0x00000680 0x000006b4 0x000006e8 0x0000071c > 0x2ab866c: 0x00000750 0x00000784 0x000007b8 0x000007ec > 0x2ab867c: 0x00000820 0x00000854 0x00000888 0x000008bc > 0x2ab868c: 0x000008f0 0x00000924 0x00000958 0x0000098c > 0x2ab869c: 0x000009c0 0x000009f4 0x00000a28 0x00000a5c > 0x2ab86ac: 0x00000a90 0x00000ac4 0x00000af8 0x00000b2c > 0x2ab86bc: 0x00000b60 0x00000b94 0x00000bc8 0x00000bfc > 0x2ab86cc: 0x00000c30 0x00000c64 0x00000c98 0x00000ccc > 0x2ab86dc: 0x00000d00 0x00000d34 0x00000d68 0x00000d9c > 0x2ab86ec: 0x00000dd0 0x00000e04 0x00000e38 0x00000e6c > 0x2ab86fc: 0x00000ea0 0x00000ed4 0x00000f08 0x00000f3c > 0x2ab870c: 0x00000f70 0x00000fa4 0x00000fd8 0x0000100c > 0x2ab871c: 0x00001040 0x00001074 0x000010a8 0x000010dc > 0x2ab872c: 0x00001110 0x00001144 0x00001178 0x000011ac > 0x2ab873c: 0x000011e0 0x00001214 0x00001248 0x0000127c > 0x2ab874c: 0x000012b0 0x000012e4 0x00001318 0x0000134c > 0x2ab875c: 0x00001380 0x000013b4 0x000013e8 0x0000141c > 0x2ab876c: 0x00001450 0x00001484 0x000014b8 0x000014ec > 0x2ab877c: 0x00001520 0x00001554 0x00001588 0x000015bc > 0x2ab878c: 0x000015f0 0x00001624 0x00001658 0x0000168c > 0x2ab879c: 0x000016c0 0x000016f4 0x00001728 0x0000175c > 0x2ab87ac: 0x00001790 0x000017c4 0x000017f8 0x0000182c > 0x2ab87bc: 0x00001860 0x00001894 0x000018c8 0x000018fc > 0x2ab87cc: 0x00001930 0x00001964 0x00001998 0x000019cc > 0x2ab87dc: 0x00001a00 0x00001a34 0x00001a68 0x00001a9c > 0x2ab87ec: 0x00001ad0 0x00001b04 0x00001b38 0x00001b6c > 0x2ab87fc: 0x00001ba0 0x00001bd4 0x00001c08 0x00001c3c > 0x2ab880c: 0x00001c70 0x00001ca4 0x00001cd8 0x00001d0c > 0x2ab881c: 0x00001d40 0x00001d74 0x00001da8 0x00001ddc > 0x2ab882c: 0x00001e10 0x00001e44 0x00001e78 0x00001eac > 0x2ab883c: 0x00001ee0 0x00001f14 0x00001f48 0x00001f7c > 0x2ab884c: 0x00001fb0 0x00001fe4 0x00002018 0x0000204c > 0x2ab885c: 0x00002080 0x000020b4 0x000020e8 0x0000211c > 0x2ab886c: 0x00002150 0x00002184 0x000021b8 0x000021ec > 0x2ab887c: 0x00002220 0x00002254 0x00002288 0x000022bc > 0x2ab888c: 0x000022f0 0x00002324 0x00002358 0x0000238c > 0x2ab889c: 0x000023c0 0x000023f4 0x00002428 0x0000245c > 0x2ab88ac: 0x00002490 0x000024c4 0x000024f8 0x0000252c > 0x2ab88bc: 0x00002560 0x00002594 0x000025c8 0x000025fc > 0x2ab88cc: 0x00002630 0x00002664 0x00002698 0x000026cc > 0x2ab88dc: 0x00002700 0x00002734 0x00002768 0x0000279c > 0x2ab88ec: 0x000027d0 0x00002804 0x00002838 0x0000286c > 0x2ab88fc: 0x000028a0 0x000028d4 0x00002908 0x0000293c > 0x2ab890c: 0x00002970 0x000029a4 0x000029d8 0x00002a0c > 0x2ab891c: 0x00002a40 0x00002a74 0x00002aa8 0x00002adc > 0x2ab892c: 0x00002b10 0x00002b44 0x00002b78 0x00002bac > 0x2ab893c: 0x00002be0 0x00002c14 0x00002c48 0x00002c7c > 0x2ab894c: 0x00002cb0 0x00002ce4 0x00002d18 0x32343231 > 0x2ab895c: 0x74653534 0x74656577 0x33746577 0x77673534 > 0x2ab896c: 0x74657274 0x33347477 0x72777120 0x20717771 > 0x2ab897c: 0x65727771 0x20777120 0x66647372 0x73616b6c > 0x2ab898c: 0x33353471 0x71772035 0x72777172 0x71727771 > 0x2ab899c: 0x77203277 0x72777172 0x71727771 0x33323233 > 0x2ab89ac: 0x6b207732 0x20657773 0x73616673 0x73207372 > 0x2ab89bc: 0x64736664 0x32343231 0x74653534 0x74656577 > 0x2ab89cc: 0x33746577 0x77673534 0x74657274 0x33347477 > 0x2ab89dc: 0x72777120 0x20717771 0x65727771 0x20777120 > 0x2ab89ec: 0x66647372 0x73616b6c 0x33353471 0x71772035 > 0x2ab89fc: 0x72777172 0x71727771 0x77203277 0x72777172 > 0x2ab8a0c: 0x71727771 0x33323233 0x6b207732 0x20657773 > 0x2ab8a1c: 0x73616673 0x73207372 0x64736664 0x32343231 > 0x2ab8a2c: 0x74653534 0x74656577 0x33746577 0x77673534 > 0x2ab8a3c: 0x74657274 0x33347477 0x72777120 0x20717771 > 0x2ab8a4c: 0x65727771 0x20777120 0x66647372 0x73616b6c > 0x2ab8a5c: 0x33353471 0x71772035 0x72777172 0x71727771 > 0x2ab8a6c: 0x77203277 0x72777172 0x71727771 0x33323233 > 0x2ab8a7c: 0x6b207732 0x20657773 0x73616673 0x73207372 > 0x2ab8a8c: 0x64736664 0x32343231 0x74653534 0x74656577 > 0x2ab8a9c: 0x33746577 0x77673534 0x74657274 0x33347477 > 0x2ab8aac: 0x72777120 0x20717771 0x65727771 0x20777120 > 0x2ab8abc: 0x66647372 0x73616b6c 0x33353471 0x71772035 > 0x2ab8acc: 0x72777172 0x71727771 0x77203277 0x72777172 > 0x2ab8adc: 0x71727771 0x33323233 0x6b207732 0x20657773 > 0x2ab8aec: 0x73616673 0x73207372 0x64736664 0x32343231 > 0x2ab8afc: 0x74653534 0x74656577 0x33746577 0x77673534 > ... > 0x2abb61c: 0x74657274 0x33347477 0x72777120 0x20717771 > 0x2abb62c: 0x65727771 0x20777120 0x66647372 0x73616b6c > 0x2abb63c: 0x33353471 0x71772035 0x72777172 0x71727771 > 0x2abb64c: 0x77203277 0x72777172 0x71727771 0x33323233 > 0x2abb65c: 0x6b207732 0x20657773 0x73616673 0x73207372 > 0x2abb66c: 0x64736664 0x537a6962 0x41706574 0x73756220 > 0x2abb67c: 0x73656e69 0x74732073 0x45617065 0x746e6576 > 0x2abb68c: 0x656d6954 0x34313032 0x2d38302d 0x32203730 > 0x2abb69c: 0x33323a31 0x2e33333a 0x62393434 0x6f4c7a69 > 0x2abb6ac: 0x69746163 0x61506e6f 0x74736972 0x736e6172 > 0x2abb6bc: 0x69746361 0x61446e6f 0x30326574 0x302d3431 > 0x2abb6cc: 0x37302d38 0x3a313220 0x333a3332 0x34342e33 > > There is plenty of compressible data once we get into the repetitive > strings in the payload part --- but that starts at offset 944, and up to > that point there is nothing that pg_lzcompress can get a handle on. There > are, by definition, no sequences of 4 or more repeated bytes in that area. > I think in principle pg_lzcompress could decide to compress the 3-byte > sequences consisting of the high-order 24 bits of each offset; but it > doesn't choose to do so, probably because of the way its lookup hash table > works: > > * pglz_hist_idx - > * > * Computes the history table slot for the lookup by the next > 4 > * characters in the input. > * > * NB: because we use the next 4 characters, we are not guaranteed to > * find 3-character matches; they very possibly will be in the wrong > * hash list. This seems an acceptable tradeoff for spreading out the > * hash keys more. > > For jsonb header data, the "next 4 characters" are *always* different, so > only a chance hash collision can result in a match. There is therefore a > pretty good chance that no compression will occur before it gives up > because of first_success_by. > > I'm not sure if there is any easy fix for this. We could possibly change > the default first_success_by value, but I think that'd just be postponing > the problem to larger jsonb objects/arrays, and it would hurt performance > for genuinely incompressible data. A somewhat painful, but not yet > out-of-the-question, alternative is to change the jsonb on-disk > representation. Perhaps the JEntry array could be defined as containing > element lengths instead of element ending offsets. Not sure though if > that would break binary searching for JSON object keys. > > regards, tom lane >
