I have a table with a field:: ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP
My question is, if I use delayed insert on this table, will the timestamp be the time when the request is queued or the time when the insert is actually made?
I have a table with a field:: ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP
My question is, if I use delayed insert on this table, will the timestamp be the time when the request is queued or the time when the insert is actually made?
The answer is when the request is queued, but that's not necessarily right when the request is made, as the request is queued after the thread for the table is established if there is not already one.
From the mysql 5.1 dev docs:
The thread executes the INSERT statement, but instead of writing the row to the table, it puts a copy of the final row into a queue that is managed by the handler thread. Any syntax errors are noticed by the thread and reported to the client program.
The order of events when the delayed statement executes:
DELAYED
lockINSERT
and put the final row into a queuedelayed_insert_limit
rows at a time and executes any pending SELECTS
between writesDELAYED
lock is releasedDepending on whether a thread needs to be created or not and how long it takes to check or obtain a DELAYED
lock, the time between the execution of the statement (step 0) and the execution of the statement (step 3) will vary. Then, depending on how large the queue is (particularly if it's over delayed_insert_limit
rows), and whether any pending SELECTS
happen, the write will be delayed by some unpredictable amount of time.
Regardless if INSERT DELAYED
is used, or if the table is locked due to another thread or update or whatnot, the value ts
will take is equal to the time the INSERT
was issued.
© 2022 - 2024 — McMap. All rights reserved.