This change is 

It would have been nice to have a separate discussion about using rst instead of markdown.

So much of the work in this document is concerned with performance and the optimizer while there are a few items in the backlog that are not. I think it would be better to keep this document entirely focused on performance and the optimizer so you don't neglect the other SQL work (ORM compatibility, JSON, etc). Trying to include every bit of SQL work would make this document to bloated.

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

docs/RFCS/sql_work_items.rst, line 926 at r1 (raw file):

   associate this data to the stage IDs

Node benchmarking

FYI, this work will likely be done by the performance team.

Comments from Reviewable

I strongly prefer if we got discussions about markup formats out of this specific PR.

Regarding the scope: I will include in this document every work item that has an influence on the architecture of the SQL middle-end. This includes, but is not limited to:

• new schema features that influence logical planning.
• new SQL features that influence the middle-end, including some parts of the work on geo-partitioning.
• further work on indexing and joining of interleaved tables.
• support for computed columns and/or computed indexes.
• items from the JSON work that influence the middle-end architecture, if any.

Issue created for the markup format: #18985.

I think this doc probably belongs as a tech note rather than an RFC (since it doesn't follow the regular rfc process or format)

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

docs/RFCS/sql_work_items.rst, line 176 at r2 (raw file):

.. raw:: html
   :file: items.embed.svg

This image is unreadably small and there doesn't seem to be a good way to zoom in on it (cmd-= kind of works, but it scrolls away from the diagram and i have to find my way back to it by scrolling with a huge font). I'm viewing the doc at https://rawgit.com/knz/cockroach/a75bd838995dd9bb840191af6c78326eb8cc0761/docs/RFCS/sql_work_items.html if that makes any difference.

docs/RFCS/sql_work_items.rst, line 1071 at r2 (raw file):

-  define a table that matches query structure to (predefined) logical
   plans;
-  define a mechanism for operators to "save" the logical plan for a

How would the operator construct a query plan other than the one that the planner would generate?

docs/RFCS/sql_work_items.rst, line 1102 at r2 (raw file):

Two possible strategies; either require the new index to already
exist (then it must store all columns already), in which case
the schema change is "small". Or implement it as a combination

What about secondary indexes that point to the existing primary key? Don't you have to rewrite those to point to the new one?

Comments from Reviewable

Review status: 0 of 8 files reviewed at latest revision, 4 unresolved discussions.

docs/RFCS/sql_work_items.rst, line 1071 at r2 (raw file):

By entering differrent SQL code or adding some hints.

The idea here is from one of our prospective customers: client app sends complicated SQL, DBA sees that, manually simplifies the query, get the simpler plan obtained this way, and "plugs it back" into the complex query sent by the client app. Perf win without having to change the client code.

docs/RFCS/sql_work_items.rst, line 1102 at r2 (raw file):

Woah, nice catch. The simpler logic works on postgres because there indexes (including PKs) store rowids, but of course that doesn't work with a KV store :)

Comments from Reviewable

Regarding this comment:

I think this doc probably belongs as a tech note rather than an RFC (since it doesn't follow the regular rfc process or format)

I initially submitted the PR as a tech node addition, then Peter suggested it should be in the RFC directory instead. I don't mind either way, just tell me what is best.

I think this doc probably belongs as a tech note rather than an RFC (since it doesn't follow the regular rfc process or format)

I initially submitted the PR as a tech node addition, then Peter suggested it should be in the RFC directory instead. I don't mind either way, just tell me what is best.

I've been interpreting RFCs as being prospective while tech-notes are retrospective (or at least, documenting the current state). Since this document is outlining future work which is open for discussion, it felt more like an RFC than a tech-note to me.

I was thinking it's a tech note because it's more of an evergreen document (it says "Never consider this document as "final".") and won't have a final "approved/rejected" disposition. But I don't feel strongly either way.

Regarding the location of the document. What do you think about one directory level higher?

My opinion: moving the doc out of the RFCs directory would cause more confusion. While the document isn't a typical RFC, it is laying out a design direction. And I'm suspicious that the document is really going to be evergreen. Certainly, Spencer's original CockroachDB design document could have been considered evergreen, yet we revisit it infrequently. My preference would be to leave it in the RFCs directory. We might update it for a while. At some point we'll write a completely new version and we'll mark this one obsolete.

The document was obsolete the week after it was written. I might keep some (local) notes about work items in the future but it seems unlikely that we can make us of a public document like this at this time. closing this.