You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Statistics from the tables are currently collected using a combination of row-execution sampler and sampleAggregator processors which have been introduced before we began implementing the vectorized engine. I believe that stats collection will benefit noticeably from the vectorized approach (similar benefits as in the other use cases - faster execution, better memory management). In particular, I'm hoping that it will alleviate issues like #54670.
The text was updated successfully, but these errors were encountered:
yuzefovich
added
the
C-enhancement
Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
label
Sep 25, 2020
@RaduBerinde I think the optimizer team needs to prioritize this for 21.1 given that #54670 is an easily reproducible OOM and we've seen a lot of OOMs related to wide rows lately. We're happy to offer guidance here.
@rytaft I thought we had hit OOMs with large rows before and had a workaround in place, do you remember the details? I think it was around dynamically adjusting the batch size or something along those lines
Maybe you're thinking of #40850? I didn't end up merging that PR since there were some performance issues identified. Seems like we should just switch to vectorized to fix this.
Statistics from the tables are currently collected using a combination of row-execution
sampler
andsampleAggregator
processors which have been introduced before we began implementing the vectorized engine. I believe that stats collection will benefit noticeably from the vectorized approach (similar benefits as in the other use cases - faster execution, better memory management). In particular, I'm hoping that it will alleviate issues like #54670.The text was updated successfully, but these errors were encountered: