Some time ago I posted PoC patch with alternative TOAST compression scheme: instead of "compress-then-chunk" I suggested "chunk-then-compress". It decrease compression level, but allows efficient arbitrary slicing.
> Could we get an similarly optimized implementation of -> operator for JSONB as well? > Are there any other potential uses? Best to fix em all up at once and then move on to other things. Thanks.
Oddly enough, I couldn't find many/any things that were sensitive to left-end decompression. The only exception is "LIKE this%" which clearly would be helped, but unfortunately wouldn't be a quick drop-in, but a rather major reorganization of the regex handling.
I had a look at "->" and I couldn't see how a slice could be used to make it faster? We don't a priori know how big a slice would give us what we want. This again makes Stephen's case for an iterator, but of course all the iterator benefits only come when the actual function at the top (in this case the json parser) are also updated to be iterative.
Committing this little change doesn't preclude an iterator, or even make doing one more complicated... :)
