Merged PRs

dolt

• 10178: Report merge conflict when merging a JSON document that is NULL in the common ancestor.
  When attempting to merge concurrent changes to a JSON document, Dolt should check whether the document is NULL in either branch or the common ancestor, and correctly report when this results in a merge conflict.
• 10155: Update datetime types to correct precision for dolt system tables
  fixes #10128
  depends on dolthub/go-mysql-server#3323
• 10120: Allow dolt_commit_diff_ to diff against HEAD
  Previously it was not possible to use 'HEAD' as a filter value on dolt_commit_diff_ system tables. This PR adds support and additional tests.

go-mysql-server

• 3328: Avoid underestimating rows in outer joins.
  When computing row estimates for joins, if the join can't be optimized into a lookup join or a merge join, we use stats to predict the fraction of pairwise combinations of left and right rows that will match and estimate the number of result rows as leftRows * rightRows * selectivity.
  This is correct for inner joins, but not correct for outer joins, because left joins guarantee at least one result per left row, and full outer joins guarentee at least one result per left or right row.
  Consider a left join where left.RowCount() is much greater than right.RowCount(), and every row of the relevant column is distinct (so left.RowCount() == left.DistinctCount(). In that case, selectivity == 1.0 / left.RowCount(), and the estimated cardinality is equal to:
  left.RowCount() * right.RowCount() * selectivity == left.RowCount() * right.RowCount() * (1.0 / left.RowCount()) ==right.RowCount().
  If the selectivity of the join is very small, this could result in a row estimate that is lower than the guaranteed minimum, which can cause the join planner to pick bad plans. In the worst case it could cause us to favor an unoptimizable join order over an optimizable one.
  A common impact of this change is to now favor hash joins for left joins when the right is much smaller than the left. This makes sense: iterating over the smaller right table once and building a hash table in memory is going to be much faster than doing a table lookup for each left row.
• 3326: Skip expected estimates and analysis for keyless table plan tests
  This is because of #10160
  These tests were supposed to be disabled in a previous PR, but plangen regenerated them.
  Thus, this PR provides a way explicitly tell plangen not to generated expected estimates, while still generating missing estimates as the default behavior.
  The difference between setting an expected value to "skip" vs omitting is how plangen treats it: plangen will generate omitted estimates (since we typically want them) but will avoid generating estimates that are explicitly skipped.
• 3325: Make IsNullable return true for log and math functions where applicable
  fixes #10102
  fixes #10157
  Like mentioned in #3308, we should do an audit of all our functions to make sure IsNullable correctly returns true if Eval can return nil for a non-nil child value. I've filed #10161 to ensure that it's on our to-do list.
• 3322: custom AppendDateFormat
  The time package's implementation of AppendDate contains additional checks and formatting options that are not necessary. Implementing a cheaper version gives us better performance.
  Benchmarks: #10150 (comment)
• 3320: Mark innodb_lock_wait_timeout as being in both global and session scopes
  We had the innodb_lock_wait_timeout system variable marked only as being in global scope, but in MySQL, it is in global and session scope.

Closed Issues

• 10157: Unexpected ANTI JOIN Result
• 10174: Does Dolt Support Minio Storage for Remotes and Backups?
• 10128: DATETIME values with microseconds are not comparable unless the literal includes the hidden fractional seconds
• 10102: Unexpected ANTI JOIN Result