TODO in veritas-optimizer-0.0.3 vs TODO in veritas-optimizer-0.0.4

@@ -1,9 +1,34 @@
+* All relations, even optimized ones, need to hold a reference to the
+  original (possibly optimized) operations.
+  * Especially "empty" relations should hold a reference to the original
+    relation so that insert/update can be performed on them if they are
+    empty not because they are valid, but because the source object is empty
+  * Materialized relations will need references to the original objects.
+
+* Optimization can replace one or more AST nodes with a simpler/more efficient
+  structure as long as it is lossless. Just changing it to empty or
+  materialized, the way things are now, we lose what the original relation
+  was so it becomes impossible to insert/update/delete from those relations.
+  * A write to a materialized object should first propagate the write down
+    to the @operand, allowing it to raise exceptions if it's read*only,
+    then it should make the change in the materialized object.
+
 * Add further optimizations:
   * Projection
-    * When it contains a Rename, if the renamed attributes are projected
-      away, then the rename can be removed.
+    * When it contains a Rename, if the renamed attributes are removed,
+      then the rename can be removed.
+    * When it contains a Restriction, if the removed attributes are *not*
+      used in the predicate, then move the Restriction to contain the
+      Projection.
+    * When renames or extensions or summarizations are projected away and
+      not used in any intermediary operation, then they can be dropped
+      altogether. There's no point in going through all that work to
+      not bother using an attribute at all. It would be better to simplify
+      the renames/extensions/summarizations to not add the attribute, and
+      then call optimize again on the op to potentially remove the op altogether
+      (like in the case of an extension adding one attribute that is removed).
   * Operation Order:
     * Projection containing an Order
       * Should remove the Order, since it is a noop
     * Projection should follow Rename
       * When a Projection contains a Restriction, wrap the Projection
@@ -71,5 +96,21 @@
   * When a restriction uses a unique index:
     * Order can be factored out
     * Limit with a limit >= 1 can be factored out
     * Offset with an offset > 0 can be transformed into an empty
       relation, since at most there can be only one match.
+
+* Summarization
+  * Add OrderSummarizePer for factoring out Order objects inside a Summarization
+  * When there are no aggregate functions, drop the Summarization and
+    return the summarize_per (?)
+    * Use the UnchangedHeader optimizer as a base class
+  * When summarize_per is TABLE_DEE, and it is wrapped by Order, at most only
+    one row can be returned, so Order can probably be dropped.
+    * Consider making relations that represents a 0 or 1 tuple relations
+      and use them in this case.
+
+* Projection
+  * It does not distribute over Intersection or Difference, but see if
+    perhaps an exception can be made if there is a functional dependency
+    between the columns projected away and the one remaining. Then I *think*
+    it might still work, but more research will be needed.