[MCOL-3277] slow update statements Created: 2019-04-23 Updated: 2023-11-10 Resolved: 2020-10-11 |
|
| Status: | Closed |
| Project: | MariaDB ColumnStore |
| Component/s: | None |
| Affects Version/s: | 1.2.3 |
| Fix Version/s: | 1.2.5 |
| Type: | New Feature | Priority: | Major |
| Reporter: | David Hill (Inactive) | Assignee: | Roman |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Environment: |
1 um 3 pm |
||
| Issue Links: |
|
||||||||||||||||
| Description |
|
Customer reported: following the recent improvements we made on importing data, the next step requires to trigger updates on billions of rows. We do this block of rows at a time, especially to fit the versionbuffer, but it looks like while the update statement by itself is ok, a lot of time is spent in flushManyAllVersion, which from my understanding invalidate the cache after the update has touched those extents/blocks. I thought lowering the numblockpct to 10% would help but it seems that this is not the case. We run updates to insert int columns matching on (varchar,int) type query in another smaller table, and run those updates sequentially with no other query running. |
| Comments |
| Comment by Andrew Hutchings (Inactive) [ 2019-04-23 ] |
|
Looks like the loops here need refactoring. If we got rid of uniquer, looped over laVptr and executed find() on fbSet we would probably hit better performance. Although with many insert/removes std::set may be faster for fbSet. |