You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Syncing metadata of two databases: If the master db has inactive indices which are missing in the target, on creation they will be activated in the target db, do a full data scan, and only afterwards they can then be deactivated by alter index. An optional "as active/inactive" clause would give more control over when an index is actually built. Oracle and MySQL have visible/invisible for indices, but that only removes the index from being used by the optimizer, it still performs a data scan on creation. Apparently the SQL standard does not regulate index creation. The syntax could be
CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]]
INDEX indexname [AS ACTIVE | INACTIVE] ON tablename
{(col [, col ...]) | COMPUTED BY (<expression>)};
ACTIVE being the default as it is now. Similar to how triggers are defined.
The text was updated successfully, but these errors were encountered:
Submitted by: Volker Rehn (vr2_s18)
Syncing metadata of two databases: If the master db has inactive indices which are missing in the target, on creation they will be activated in the target db, do a full data scan, and only afterwards they can then be deactivated by alter index. An optional "as active/inactive" clause would give more control over when an index is actually built. Oracle and MySQL have visible/invisible for indices, but that only removes the index from being used by the optimizer, it still performs a data scan on creation. Apparently the SQL standard does not regulate index creation. The syntax could be
CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]]
INDEX indexname [AS ACTIVE | INACTIVE] ON tablename
{(col [, col ...]) | COMPUTED BY (<expression>)};
ACTIVE being the default as it is now. Similar to how triggers are defined.
The text was updated successfully, but these errors were encountered: