Mitar:
On Fri, Apr 23, 2021 at 7:33 PM Mitar <mmitar@gmail.com> wrote:
> On Fri, Apr 23, 2021 at 10:28 AM Francisco Olarte
> <folarte@peoplecall.com> 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.
