* Josh Berkus (j...@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
signature.asc
Description: Digital signature