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.
ср, 20 февр. 2019 г., 2:09 Paul Ramsey pram...@cleverelephant.ca: > On Sat, Feb 16, 2019 at 7:25 AM Simon Riggs <si...@2ndquadrant.com> wrote: > > > 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... :) > > P. > >
