On Sep 4, 2014, at 7:26 PM, Jan Wieck <jan@wi3ck.info> wrote:
> This is only because the input data was exact copies of the same strings over and over again. PGLZ can very well
compressslightly less identical strings of varying lengths too. Not as well, but well enough. But I suspect such input
datawould make it fail again, even with lengths.
We had a bit of discussion about JSONB compression at PDXPUG Day this morning. Josh polled the room, and about half
thoughwe should apply the patch for better compression, while the other half seemed to want faster access operations.
(Somefolks no doubt voted for both.) But in the ensuing discussion, I started to think that maybe we should leave it as
itis, for two reasons:
1. There has been a fair amount of discussion about ways to better deal with this in future releases, such as hints to
TOASTabout how to compress, or the application of different compression algorithms (or pluggable compression). I’m
assumingthat leaving it as-is does not remove those possibilities.
2. The major advantage of JSONB is fast access operations. If those are not as important for a given use case as
storagespace, there’s still the JSON type, which *does* compress reasonably well. IOW, We already have a JSON
alternativethe compresses well. So why make the same (or similar) trade-offs with JSONB?
Just my $0.02. I would like to see some consensus on this, soon, though, as I am eager to get 9.4 and JSONB, regardless
ofthe outcome!
Best,
David