Merged PRs

dolt

• 8144: Don't panic when performing a GC on a shallow clone
• 8143: Add support for visualizing prolly tree and blob messages in dolt show
  This PR does a couple things:
  1. dolt show #address can now display the internals of a ProllyTreeMap message (typically used for storing indexes). Previously, only splunk/noms show could do this.
  2. Both dolt show and splunk can now display the contents of a Blob message.
  3. If a ProllyTreeMap leaf node contains a value that is itself an address (example: the value of text and json columns), that value is shown as a human readable address, which can be fed back into dolt show or splunk to explore the whole tree.
• 8141: support STAGED as commit hash
  This PR adds support for STAGED as a commit_hash when filtering dolt diff system tables.
  fixes for #7978
• 8140: Continue to support writes when archives are in play
  Error in hasMany effectively prevented writes after moving database to archives.
• 8084: enable key range iter
  There was an issue merging #8025 ontop of a revert. Enable the key iteration optimization.
• 8072: [rowexec] dolt-side lookup execution operator
  This PR adds custom Dolt execution operators for lookup joins. When building an execution plan, we try to replace joinIter with a Dolt equivalent that inlines the key building and map get. This is a lot faster than repeatedly building the secondary iterator and materializing sql.Rows in-between lookups.
  The main downside is that this PR hoists filters in join children to after materializing lookup join rows.
  This brings index_join from 5.18 ms/query to 2.64 ms/q, which will be about 2.0x MySQL's latency.
  This PR falls short of some aspiration goals:
  • We hoist table filters until after the final join row is built because we don't have a way to call scalar expressions on val.Tuple yet. There are edge case queries that might be dramatically slower because of this. To fix this, we could need to convert sql.Expression filters into a format that we could execute on val.Tuple KV pairs.
  • We do not yet try to to optimize consecutive lookup joins. I'm not sure if a materialization block would be better represented iteratively or recursively beyond a simple string of lookups. A lot of interfaces and indexing considerations to think about there.
    Safety comments:
  • we fallback to GMS when lookup source/dest keys are not prolly.Encoding compatible
  • the source iterators are the same as what we used before, but without projection mapping to sql.Rows. The keyless iterator required a change to return duplicate rows at the KV layer (vs the sql layer).
  • the secondary iterators are a generalization of what we currently use, but return KV pairs instead of rows
  • projection mapping is the same but generalized to merge an arbitrary list of KV pairs after the join
    There are extra tests here: dolthub/go-mysql-server#2593

go-mysql-server

• 2598: Adding the binlog_expire_logs_seconds system variable
  MySQL @@binlog_expire_logs_seconds reference docs
• 2596: Fix information_schema.columns for databases with schemas
  Missed this table in my original PR
• 2593: custom row exec
  Additions for custom row operators on Dolt side: #8072

Closed Issues

• 8126: CREATE DATABASE statements should not create databases hierarchicaly
• 7698: Incorrect return typefor UNIX_TIMESTAMP
• 7978: Should be able to use "STAGED" as commits in dolt_commit_diff_[tablename]
• 8131: Docker Mysql Server Resets When Connecting Immediately After Launch