On 2019-02-20 08:39:38 +0000, Simon Riggs wrote: > On Tue, 19 Feb 2019 at 23:09, Paul Ramsey <pram...@cleverelephant.ca> wrote: > > > 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... :) > > > > Sure, but we have the choice between something that benefits just a few > cases or one that benefits more widely. > > If we all only work on the narrow use cases that are right in front of us > at the present moment then we would not have come this far. I'm sure many > GIS applications also store JSONB data, so you would be helping the > performance of the whole app, even if there isn't much JSON in PostGIS.
-1, I think this is blowing up the complexity of a already useful patch, even though there's no increase in complexity due to the patch proposed here. I totally get wanting incremental decompression for jsonb, but I don't see why Paul should be held hostage for that. Greetings, Andres Freund
