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
• 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. The tableEditAccumulator seems to be the only place, and it is discarded after it goes through flushEditAccumulator, so that doesn't seem to be it. However, setting its fields to nil fixes the leak, indicating that there is somewhere holding on to old tableEditAccumulators. I also checked if async.ActionExecutor was the culprit, but manual debugging and testing showed that it wasn't holding on to any references once they went through the work method. This isn't a true fix, as there is still technically a leak for whatever is holding on to the tableEditAccumulator, but it's a leak of mere kilobytes per hour rather than megabytes per minute.
  Here is an image from pprof 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