distsql: implement distributed DISTINCT

[irfansharif]

Implementation of the Distinct processor core type, pretty trivial. Can't think of a verb form for distinct, distinguisher seems off but no strong opinions here. Sent this PR out now for early review, now writing out the optimizations for pre-existing ordering in the input rows taking advantage of the fact that the seen set can be reset whenever we find consecutive rows differing on a prefix comprised of ordered columns.

Part of #7587.
cc @RaduBerinde, @andreimatei

---

This change is

[RaduBerinde]

---

Review status: 0 of 7 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

---

pkg/sql/distsql/distinct.go, line 125 at r1 (raw file):

  }

  return sqlbase.EncodeDTuple(b, d.tuple)

EncDatum has an Encode function. Using that instead of going to a Tuple and EncodeDTuple can be more efficient - the desired encoding matches the one we already have, we can avoid decoding and reencoding.

---

Comments from Reviewable

[irfansharif]

TFTR, pulling it in now.

---

Review status: 0 of 7 files reviewed at latest revision, 1 unresolved discussion, all commit checks successful.

---

pkg/sql/distsql/distinct.go, line 125 at r1 (raw file):

Previously, RaduBerinde wrote…

EncDatum has an Encode function. Using that instead of going to a Tuple and EncodeDTuple can be more efficient - the desired encoding matches the one we already have, we can avoid decoding and reencoding.

Done.

---

Comments from Reviewable

[RaduBerinde]

pkg/sql/distsql/distinct.go, line 118 at r2 (raw file):

      enc, ok := row[col].Encoding()
      if !ok {
          return nil, errors.Errorf("encoding not available for %s", row[col])

We need to fix an encoding for each column and always use that. Different rows may come with different encodings, e.g. if they come from different streams that were merged. Then the encodings won't match. Also, this no-encoding case is legitimate - e.g. a new result from an Evaluator will have a Datum but no encoding.

It's ok for now to just always choose DatumEncoding_VALUE with a TODO to maybe check the first row for what encodings are already available.

---

Comments from Reviewable

[irfansharif]

Review status: 0 of 7 files reviewed at latest revision, 2 unresolved discussions, all commit checks successful.

---

pkg/sql/distsql/distinct.go, line 118 at r2 (raw file):

Previously, RaduBerinde wrote…

We need to fix an encoding for each column and always use that. Different rows may come with different encodings, e.g. if they come from different streams that were merged. Then the encodings won't match. Also, this no-encoding case is legitimate - e.g. a new result from an Evaluator will have a Datum but no encoding.

It's ok for now to just always choose DatumEncoding_VALUE with a TODO to maybe check the first row for what encodings are already available.

will update this with the partial ordering optimization PR.

---

Comments from Reviewable