add index to blocks' consensus

[ayrat555]

Motivation

Some slow queries use consensus field in blocks table:

SELECT b1."number" FROM "blocks" AS b0 INNER JOIN "blocks" AS b1 ON b1."hash" = b0."parent_hash" WHERE (b0."consensus" = TRUE) AND (b1."consensus" = FALSE)

After migration, added index (blocks_consensus_index) is used in this query

Gather  (cost=1000.99..141914.57 rows=67195 width=8)
  Workers Planned: 1
  ->  Nested Loop  (cost=0.99..134195.07 rows=39526 width=8)
        ->  Parallel Index Scan using blocks_consensus_index on blocks b1  (cost=0.43..4864.70 rows=39904 width=41)
              Index Cond: (consensus = false)
              Filter: (NOT consensus)
        ->  Index Only Scan using one_consensus_child_per_parent on blocks b0  (cost=0.56..3.24 rows=1 width=33)
              Index Cond: (parent_hash = b1.hash)

Changelog

• add index to blocks' consensus

[coveralls]

Pull Request Test Coverage Report for Build d2f2e653-8ff0-47a4-bff2-e267705dc021

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 84.888%

---

Totals
Change from base Build f5454a4c-36cb-48cd-8283-20b2d5b2f402:	0.0%
Covered Lines:	4269
Relevant Lines:	5029

---

💛 - Coveralls

[vbaranov]

Are there any time estimations of how a query works before and after index implementing?

[vbaranov]

@ayrat555 ☝️

[ayrat555]

@vbaranov

"Gather  (cost=1000.56..316544.24 rows=67195 width=8)"
"  Workers Planned: 2"
"  ->  Nested Loop  (cost=0.56..308824.74 rows=27998 width=8)"
"        ->  Parallel Seq Scan on blocks b1  (cost=0.00..217216.81 rows=28265 width=41)"
"              Filter: (NOT consensus)"
"        ->  Index Only Scan using one_consensus_child_per_parent on blocks b0  (cost=0.56..3.24 rows=1 width=33)"
"              Index Cond: (parent_hash = b1.hash)"

Here a query without the index. Parallel Seq Scan is much more expensive operation