Application start takes too much time - Closes #2426 #2485
Conversation
db/sql/migrations/runtime.sql
Outdated
| DROP TABLE mem_accounts2u_delegates; | ||
| CREATE TABLE mem_accounts2u_delegates AS TABLE mem_accounts2delegates; | ||
| ALTER TABLE mem_accounts2u_delegates ADD CONSTRAINT "mem_accounts2u_delegates_accountId_fkey" FOREIGN KEY ("accountId") REFERENCES mem_accounts(address) ON DELETE CASCADE; | ||
| CREATE INDEX "mem_accounts2u_delegates_accountId" ON mem_accounts2u_delegates("accountId"); | ||
|
|
||
| DELETE FROM mem_accounts2u_multisignatures; | ||
| INSERT INTO mem_accounts2u_multisignatures ("accountId", "dependentId") SELECT "accountId", "dependentId" FROM mem_accounts2multisignatures; |
There was a problem hiding this comment.
Please make the change also for this query.
There was a problem hiding this comment.
I will though impact was less as it was changing a small number of rows but it makes sense for both queries to look the same
There was a problem hiding this comment.
Yep, just for consistency. Also, there are some unit tests that are not passing after the change.
There was a problem hiding this comment.
Yeah checking the unit tests but I think they were not passing without the change; Just merged develop back in and will check again.
There was a problem hiding this comment.
It's because of the change in this PR:
16:50:10 MigrationsRepository
16:50:10 applyRuntime()
16:50:10 should set peers to disconnected mode and clock to NULL for non-banned peers:
16:50:10
16:50:10 �[31mAssertionError: expected 0 to deeply equal 1�[0m
16:50:10 �[32m+ expected�[0m �[31m- actual�[0m
16:50:10
16:50:10 �[31m-0�[0m
16:50:10 �[32m+1�[0m
16:50:10 �[0m�[90m
16:50:10 at Context.<anonymous> (test/unit/db/repos/migrations.js:170:38)
16:50:10 at Generator.next (<anonymous>:null:null)
16:50:10 at onFulfilled (node_modules/co/index.js:65:19)
16:50:10 at tryCatcher (node_modules/bluebird/js/release/util.js:16:23)
16:50:10 at Promise._settlePromiseFromHandler (node_modules/bluebird/js/release/promise.js:512:31)
16:50:10 at Promise._settlePromise (node_modules/bluebird/js/release/promise.js:569:18)
16:50:10 at Promise._settlePromise0 (node_modules/bluebird/js/release/promise.js:614:10)
16:50:10 at Promise._settlePromises (node_modules/bluebird/js/release/promise.js:693:18)
16:50:10 at Async._drainQueue (node_modules/bluebird/js/release/async.js:133:16)
16:50:10 at Async._drainQueues (node_modules/bluebird/js/release/async.js:143:10)
16:50:10 at Immediate.Async.drainQueues [as _onImmediate] (node_modules/bluebird/js/release/async.js:17:14)
16:50:10
Co-Authored-By: pablitovicente <pvicente@gmail.com>
Co-Authored-By: pablitovicente <pvicente@gmail.com>
| ALTER TABLE mem_accounts2u_multisignatures ADD CONSTRAINT "mem_accounts2u_multisignatures_accountId_fkey" FOREIGN KEY ("accountId") REFERENCES mem_accounts(address) ON DELETE CASCADE; | ||
| CREATE INDEX IF NOT EXISTS "mem_accounts2u_multisignatures_accountId" ON mem_accounts2u_multisignatures("accountId"); | ||
|
|
||
|
|
There was a problem hiding this comment.
Should not we just disable the indexes on table for data import and then enable them back and reindex the table, instead of this approach?
UPDATE pg_index
SET indisready=false
WHERE indrelid = (
SELECT oid
FROM pg_class
WHERE relname='<TABLE_NAME>'
);There was a problem hiding this comment.
Same for constraints...
ALTER TABLE TableName NOCHECK CONSTRAINT ConstraintName;and later
ALTER TABLE TableName CHECK CONSTRAINT ConstraintName;
|
As discussed with @4miners the above approach will be used temperately and later we are not going to need these unconfirmed tables. Then will remove this logic completely. |
What was the problem?
Application startup was too slow due to SQL in migration /db/sql/migrations/runtime.sql
How did I fix it?
@4miners suggested faster queries
How to test it?
time node app -n testnetusing the old queries (take note of the time)time node app -n testnetusing the queries in this PR (take note of the time and compare with previous time)Review checklist