sql/parser: parsing for interleaved tables/indexes

[danhhz]

I ran doc generation locally and the SKIP DOC seems to work and keep this off
the diagrams.

For #2972.

---

This change is

[RaduBerinde]

---

Review status: 0 of 8 files reviewed at latest revision, all discussions resolved, some commit checks failed.

---

Comments from Reviewable

[petermattis]

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

---

sql/parser/parse_test.go, line 101 [r1] (raw file):

      {`CREATE TABLE a (b INT, c TEXT, INDEX d (b, c))`},
      {`CREATE TABLE a (b INT, c TEXT, CONSTRAINT d UNIQUE (b, c))`},
      {`CREATE TABLE a (b INT, c TEXT, CONSTRAINT d UNIQUE (b, c) INTERLEAVE IN PARENT d (e, f))`},

When interleaving an index, I assume we're only going to allow interleaving the index in the table it is part of. So perhaps the parent name should be omitted in this case and the CREATE INDEX statement.

---

Comments from Reviewable

[petermattis]

Review status: 0 of 8 files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

---

sql/parser/sql.y, line 1599 [r1] (raw file):

index_def:
  INDEX opt_name '(' index_params ')' opt_storing opt_interleave

Using opt_interleave here means that opt_drop_behavior also applies, but CASCADE is always the rule for indexes. I think you'll need different rules for index vs table interleave statements.

---

Comments from Reviewable

[danhhz]

Review status: 0 of 8 files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

---

sql/parser/parse_test.go, line 101 [r1] (raw file):

Previously, petermattis (Peter Mattis) wrote…

When interleaving an index, I assume we're only going to allow interleaving the index in the table it is part of. So perhaps the parent name should be omitted in this case and the CREATE INDEX statement.

I don't see any reason not to allow interleaving an index for one table into the data for another. As far as I see, it doesn't complicate the implementation of interleaving and maybe it will be useful? It reduces an index join from hitting three ranges to two.

---

sql/parser/sql.y, line 1599 [r1] (raw file):

Previously, petermattis (Peter Mattis) wrote…

Using opt_interleave here means that opt_drop_behavior also applies, but CASCADE is always the rule for indexes. I think you'll need different rules for index vs table interleave statements.

If we allow interleaving an index into some other table as I suggest above, then I think the "CASCADE is always the rule" part doesn't apply.

---

Comments from Reviewable

[petermattis]

---

Review status: 0 of 8 files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

---

sql/parser/parse_test.go, line 101 [r1] (raw file):

Previously, paperstreet (Daniel Harrison) wrote…

I don't see any reason not to allow interleaving an index for one table into the data for another. As far as I see, it doesn't complicate the implementation of interleaving and maybe it will be useful? It reduces an index join from hitting three ranges to two.

Ah, so this was intentional. It feels a bit odd. On the other hand, interleaving an index in the table it is associated with isn't terribly useful given that for any row in the table there will be only a single row in the index.

---

Comments from Reviewable

[RaduBerinde]

sql/parser/parse_test.go, line 101 [r1] (raw file):

Previously, petermattis (Peter Mattis) wrote…

Ah, so this was intentional. It feels a bit odd. On the other hand, interleaving an index in the table it is associated with isn't terribly useful given that for any row in the table there will be only a single row in the index.

Yeah I don't see why you would ever interleave an index with that same table.

Interleaving with another table can be useful. Here's an example - we have a table of customers (customerID PK) and a table of orders (orderID PK, each order also includes the customerID). We could have a (customerID, orderID, sum) index on orders and interleave that into the customer table; this would speed up joining by customerID (e.g. for generating a report with customer names and how much each one spent).

---

Comments from Reviewable