* Josh Berkus (josh@agliodbs.com) wrote:
> On 08/08/2014 08:02 AM, Tom Lane wrote:
> > 2. Are we going to ship 9.4 without fixing this? I definitely don't see
> > replacing pg_lzcompress as being on the agenda for 9.4, whereas changing
> > jsonb is still within the bounds of reason.
> >
> > Considering all the hype that's built up around jsonb, shipping a design
> > with a fundamental performance handicap doesn't seem like a good plan
> > to me. We could perhaps band-aid around it by using different compression
> > parameters for jsonb, although that would require some painful API changes
> > since toast_compress_datum() doesn't know what datatype it's operating on.
>
> I would rather ship late than ship a noncompressable JSONB.
>
> One we ship 9.4, many users are going to load 100's of GB into JSONB
> fields. Even if we fix the compressability issue in 9.5, those users
> won't be able to fix the compression without rewriting all their data,
> which could be prohibitive. And we'll be in a position where we have
> to support the 9.4 JSONB format/compression technique for years so that
> users aren't blocked from upgrading.
Would you accept removing the binary-search capability from jsonb just
to make it compressable? I certainly wouldn't. I'd hate to ship late
also, but I'd be willing to support that if we can find a good solution
to keep both compressability and binary-search (and provided it doesn't
delay us many months..).
Thanks,
Stephen
