[MDEV-16356] Allow ALGORITHM=NOCOPY for ADD CONSTRAINT Created: 2018-05-31  Updated: 2024-01-18

Status: Open
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Fix Version/s: None

Type: Task Priority: Major
Reporter: Marko Mäkelä Assignee: Oleksandr Byelkin
Resolution: Unresolved Votes: 2
Labels: CONSTRAINT, foreign-keys, online-ddl

Issue Links:
Blocks
blocks MDEV-16291 Allow ALGORITHM=NOCOPY for most ALTER... Open
blocks MDEV-16354 Allow ALGORITHM=INPLACE for ADD COLUM... Open
blocks MDEV-30669 Changing the Data Type of a Column fr... Open
is blocked by MDEV-31008 Instant ALTER allows to violate colum... Confirmed
Relates
relates to MDEV-30416 Can't redefine constraint in a single... Confirmed
relates to MDEV-32171 When updating cascaded foreign keys, ... Closed
relates to MDEV-32270 ALTER TABLE: DROP CONSTRAINT is ignor... Confirmed
relates to MDEV-16332 Allow ALGORITHM=NOCOPY or INSTANT for... Confirmed
relates to MDEV-19453 FK errors are hidden behind an obscur... Open
relates to MDEV-28298 Add Foreign key to a table instantly ... Open
relates to MDEV-30788 ONLINE Add Foreign Key Closed
relates to MDEV-30934 InnoDB: Changing a Column Data Type f... Open
relates to MDEV-33087 ALTER TABLE...ALGORITHM=COPY should b... Confirmed

 Description   

The ADD FOREIGN KEY and ADD CHECK constraints currently require the table to be rebuilt with ALGORITHM=COPY.

We could support these operations instantly if the user specified a WITHOUT VALIDATION clause. We currently do support instant ADD FOREIGN KEY after SET foreign_key_checks=0, but there is no such mechanism for ADD CONSTRAINT CHECK.

When validation is not suppressed, we should only scan the table and validate the added constraints. There is no need to write any data to the table. For LOCK=NONE operation, we may need to ‘subscribe’ to concurrent modifications somehow.



 Comments   
Comment by Alexander Barkov [ 2023-03-24 ]

This feature would solve the problem described in MDEV-30669 (TEXT to JSON conversion).

Comment by Marko Mäkelä [ 2023-03-24 ]

I think that this is easiest to implement in the SQL layer. For checking FOREIGN KEY constraints, some type of join (outer join?) will be necessary. For anything else (CHECK or JSON validity constraints or adding a NOT NULL attribute to a column in a ROW_FORMAT=REDUNDANT table), a plain table scan would do. In the storage engine, this can be facilitated by the same APIs that serve regular SELECT and joins.

Generated at Thu Feb 08 08:28:17 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.