Re: jsonb format is pessimal for toast compression
От | Ants Aasma |
---|---|
Тема | Re: jsonb format is pessimal for toast compression |
Дата | |
Msg-id | CA+CSw_sPqqtcB32d+6QW918zi3bmx-O2sPRmYezOeOcCbnHjeg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: jsonb format is pessimal for toast compression (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: jsonb format is pessimal for toast compression
|
Список | pgsql-hackers |
On Fri, Aug 8, 2014 at 7:35 PM, Andrew Dunstan <andrew@dunslane.net> wrote: >> I took a quick look and saw that this wouldn't be that easy to get around. >> As I'd suspected upthread, there are places that do random access into a >> JEntry array, such as the binary search in findJsonbValueFromContainer(). >> If we have to add up all the preceding lengths to locate the corresponding >> value part, we lose the performance advantages of binary search. AFAICS >> that's applied directly to the on-disk representation. I'd thought >> perhaps there was always a transformation step to build a pointer list, >> but nope. > > It would be interesting to know what the performance hit would be if we > calculated the offsets/pointers on the fly, especially if we could cache it > somehow. The main benefit of binary search is in saving on comparisons, > especially of strings, ISTM, and that could still be available - this would > just be a bit of extra arithmetic. I don't think binary search is the main problem here. Objects are usually reasonably sized, while arrays are more likely to be huge. To make matters worse, jsonb -> int goes from O(1) to O(n). Regards, Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de
В списке pgsql-hackers по дате отправления: