Pre-process mutations to optimize table modifications.
Review Request #5180 — Created Dec. 31, 2013 and submitted — Latest diff uploaded
Pre-process mutations to optimize table modifications.
Database mutations are now pre-processed in order to filter out
mutations that ultimately have no effect on the database, or those that
can be easily combined into earlier mutations.Lists of mutations are first divided up into batches of mutations that
can be considered together (AddField
,ChangeField
,RenameField
,
DeleteField
, basically). Each batch is then processed for a number of
optimizations.The optimizations include:
-
Removing all mutations for a batch that both adds and deletes a
particular field, which would otherwise result in an expensive
no-op on the table. -
Removing all mutations operating on a field that's later deleted in
aDeleteField
. -
Condensing multiple
ChangeField
s in a batch together into one
ChangeField
. -
Condensing all changes made by
ChangeField
s for a field into the
AddField
that introduced the field, if anAddField
is present in the
batch. -
Condensing multiple
RenameField
s in a batch together into a single
RenameField
. -
Removing all
RenameField
s and changing the field name for anAddField
when both are present in a batch.
This can reduce the time needed for evolutions by a fair amount,
particularly when upgrading an older database with many changes pending.
- Introduced a bunch of unit tests, which all pass.
- Ran against a RB 1.7.x database. It evolved, and the number of
ALTER TABLE
statements was reduced by 5.