0.18.2
We have released Dolt 0.18.2 with bug fixes, performance improvements (mainly around memory usage), and improvements to the way we handle merges.
Merged PRs
- 824: /.github/workflows/ci-bats-tests.yaml: revert changes now that breaki…
fixed here https://github.community/t/github-action-environment-variable-missing-breaking-issue/125913 - 823: /.github/workflows/ci-bats-tests.yaml: Skip aws remotes bats tests
- 822: /go/go.mod: update eventsapi generated types
related to #816 - 820: foreign keys can use primary keys as parent table indexes
This change makes a special case for foreign keys that reference primary key(s) in the parent table. If all of the parent table columns are primary keys, we create an index to use for the foreign key.
Ideally we'd make use of the existing clustered index as the parent table index. Because we will soon be adding keyless tables and allowing primary key changes, I'm punting, for now, on a more elegant implementation. - 814: Fixed memory leak when running sqllogictests
Performance seems roughly the same compared to the pre-FK changes from my testing. Perhaps not the best solution, but it fixes the leak while preserving performance. - 813: Foreign Key, Index changes
- Added
diff
support for foreign keys and indexes - Updated commit, stage, and reset logic to match tables based on column tags instead of table names
- Added
- 812: Andy/range reader empty map
- 811: Andy/foreign key changes
- 807: ALTER TABLE x ADD INDEX unnamed
- 805: Added support and tests for CREATE TABLE INDEX
- 804: Resolved memory leak
Fixes a memory leak that was observed during a large import. It appears that the primary key tuples were never deallocating, although I could not pinpoint what's holding on to the tuples. ThetableEditAccumulator
seems to be the only place, and it is discarded after it goes throughflushEditAccumulator
, so that doesn't seem to be it. However, setting its fields tonil
fixes the leak, indicating that there is somewhere holding on to oldtableEditAccumulator
s. I also checked ifasync.ActionExecutor
was the culprit, but manual debugging and testing showed that it wasn't holding on to any references once they went through thework
method. This isn't a true fix, as there is still technically a leak for whatever is holding on to thetableEditAccumulator
, but it's a leak of mere kilobytes per hour rather than megabytes per minute.
Here is an image frompprof
from before.
Same query, but with the changes. Will not be equal to zero as the tuples (returned from here) are still stored in memory before being written to disk, so this is what we'd expect/desire.
Also verified each by watching memory usage in Task Manager (Windows 10). - 800: Updated version for release of version 0.18.1
- 149: Added indexes to CREATE TABLE
- 147: create parent table indexes for foreign keys