Mitar: On Fri, Apr 23, 2021 at 7:33 PM Mitar <mmitar@xxxxxxxxx> wrote: > On Fri, Apr 23, 2021 at 10:28 AM Francisco Olarte > <folarte@xxxxxxxxxxxxxx> wrote: > > A fast look at the link. It seems to be long string of random LOWER > > CASE HEX DIGITS. A simple huffman coder can probably put it in 5 bits > > per char, and a more sophisticated algorithm can probably approach 4. > But this compression-ility would apply to both JSONB and JSON column > types, no? Moreover, it looks like JSONB column type ends up larger on > disk. Of course, I did not follow the thread to deeply, just pointed that in case you were assuming that was not going to be stored compressed. Also, not surprised JSONB ends up being fatter, when no binary data is transmitted and no compression is used compact JSON has very little redundancy, about 6 chars per k/v pair, this is hard to beat without using sophisticated encodings, especially with long data. And if jsonb starts up bigger, and IIRC it does trade off compactness to be easily indexable an other stuff, it will normally end up bigger. But not an expert on this. FOS.
