[MDEV-8368] CONNECT engine mysql table type require a table level lock every time when inserting Created: 2015-06-24 Updated: 2015-08-03 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - Connect |
| Fix Version/s: | None |
| Type: | Task | Priority: | Minor |
| Reporter: | tramchamploo | Assignee: | Olivier Bertrand |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
It causes the delay on high concurrency insertion. |
| Comments |
| Comment by Olivier Bertrand [ 2015-07-16 ] |
|
Can you elaborate and give an example? |
| Comment by Sergei Golubchik [ 2015-07-17 ] |
|
I suspect the original reporter uses “mysql” table type to connect to an InnoDB table. InnoDB supports row-level locks, so perhaps the CONNECT table that connects to InnoDB might use row-level locks too. Currently CONNECT always uses table-level locks, see ha_connect::store_lock. For row-level locks, this method needs to downgrade table locks to TL_WRITE_ALLOW_WRITE, see how complex ha_innobase::store_lock is. May be you can do no locking for “mysql” table type at all — and rely on the locks on the underlying table. Or may be not, I'm not sure it'll work. |
| Comment by Olivier Bertrand [ 2015-07-17 ] |
|
What does FEDERATED about locking? It should be interresting to compare the difference between CONNECT and FEDERATED in high concurrency insertion. |
| Comment by Sergei Golubchik [ 2015-08-03 ] |
|
See ha_federatedx::store_lock(). It downgrades the lock to TL_WRITE_ALLOW_WRITE and sometimes to TL_READ. |