Maybe I haven't read WL#4284 closely enough, but I worry that it
may not fit well with on-line DDL operations. If the server serializes
DDL and DML operations, then they're not really on-line are they?
Falcon currently implements on-line add index, on-line drop index,
on-line add column, on-line drop column, and on-line alter column.
(The column operations are ifdef'd out because of a bug in the
remapping of column identifiers in an update when several formats
of the record exist.)
On-line add index should not block concurrent access to the table,
including inserts, updates, and deletes.
On-line drop index should not block concurrent access to the table,
but should prevent new queries from being optimized with that index
and should wait until existing queries that use the index complete.
Accessing a dropped index in Falcon is messy.
Adding a column on-line should not block concurrent access to the
table, including inserts, updates, and deletes.
Because of the way Falcon handles table descriptions, dropping
and altering a column can be done without blocking DML operations.
(Tables have formats. Records carry the version number of the
format under which they were created. Requests include the format
version they expect. Falcon converts between formats on the fly
in memory. Records on disk change format when they are updated.)
Is there provision in WL#4284 to recognize on-line DDL operations?
|• Worklog #4284 and on-line DDL||Ann W. Harrison||5 Nov|