Hadi Moshayedi <h...@moshayedi.net> writes: > The attached patch improves the performance of array_length() by detoasting > only the overhead part of the datum.
It looks to me like this would actually make things worse for cases where the input array wasn't toasted-out-of-line (because it would uselessly make a copy of the header part, costing a palloc cycle). I'm not averse to improving the case you're worried about, but you have to pay attention to not having bad side-effects on other cases. Another thought is that this can only win for arrays that are external without being compressed; when they are compressed, then heap_tuple_untoast_attr_slice will fetch and decompress the entire array anyway (and then, just to add insult to injury, make another copy :-(). With that in mind, I was surprised that your test case showed any improvement at all --- it looks like the arrays aren't getting compressed for some reason. There are going to be a lot of other cases where this patch doesn't help unless the user turns off compression, which will hurt his performance in other ways. Now, the slice detoast support was only designed to work with data stored in "external" mode (that is, with compression manually disabled via the appropriate ALTER TABLE option), and that's not unreasonable for its originally-intended application of being able to fetch any part of an external text string. But it strikes me that for what you want here, namely fetching just a few bytes from the start, it ought to be possible to do better. Could we teach the toast code to fetch and decompress just an initial subset of the data? (This might be useful even for the original use-case of slice fetches, as long as the desired slice isn't too close to the end of the datum.) Bottom line for me is that you've shown that there can be a win from improving this code, but we need to do some basic work on the slice-fetching logic to get full value out of the idea. > Of course this technique is applicable to some other functions too, but > they have never become a bottleneck for me, so I decided to keep the > changes only to this function. I would expect a committable version of this patch to cover all the array-dimension-related functions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers