Fix performance of address page for validators

[vbaranov]

#2306

Motivation

The issue with the performance of address's page is related only to validators and the slowest part is the query to get block rewards for validators. The problem is that some validators changed their payout keys. It means that once upon a time they have been getting rewards on their mining key and after the change, they began to get rewards to their payout key. Thus, opening the address page for mining key of validator somewhere deeply in block_rewards table we have rows for the rewards for that mining key but since we ordering by block numbers in descending order, the query works very slow to get 50 rows. I think we should get rewards only for the latest blocks. Let's say the last 2000 blocks - it is enough to keep track of rewards on the first 3 pages of chain with 20 validators. I doubt someone will look deeper than 2nd page looking for rewards.

Changelog

The query that slows down address page:

SELECT b0."address_type", b0."reward", b0."address_hash", b0."block_hash", b0."inserted_at", b0."updated_at"
FROM "block_rewards" AS b0
INNER JOIN "blocks" AS b1
ON b1."hash" = b0."block_hash"
WHERE (b0."address_hash" = '\x5ee341ac44d344ade1ca3a771c59b98eb2a77df2')
ORDER BY b1."number" DESC LIMIT 1;

it is suggested to change it to:

SELECT b0."address_type", b0."reward", b0."address_hash", b0."block_hash", b0."inserted_at", b0."updated_at"
FROM "block_rewards" AS b0 
INNER JOIN (SELECT b0.* FROM "blocks" AS b0 ORDER BY b0."number" 
DESC LIMIT 1000) AS s1 ON s1."hash" = b0."block_hash"
WHERE (b0."address_hash" = '\x5ee341ac44d344ade1ca3a771c59b98eb2a77df2')
ORDER BY s1."number" DESC LIMIT 1

Before:

After:

UPDATE 2019-12-12

I found a way how to increase the performance of the validators' address' page even without limiting the number of taking to account rewards. The idea is to get the range of blocks where transactions found for this page of the transactions' list in the pagination and show rewards, that are in the block's range. Even despite that fact that page will wait retrieving of this blocks' range first to proceed with rewards query, page works dramatically faster.

Checklist for your Pull Request (PR)

• I added an entry to CHANGELOG.md with this PR
• If I added new functionality, I added tests covering it.
• If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.
• I checked whether I should update the docs and did so by submitting a PR to https://github.com/blockscout/docs
• If I added/changed/removed ENV var, I submitted a PR to https://github.com/blockscout/docs to update the list of env vars at https://github.com/blockscout/docs/blob/master/for-developers/information-and-settings/env-variables.md and I updated the version to master in the Version column. Changes will be reflected in this table: https://docs.blockscout.com/for-developers/information-and-settings/env-variables.
• If I add new indices into DB, I checked, that they are not redundant with PGHero or other tools

[coveralls]

Pull Request Test Coverage Report for Build c4f55590-f3fc-42d0-b14b-d3adfdbb3946

• 21 of 28 (75.0%) changed or added relevant lines in 2 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.03%) to 75.218%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
apps/explorer/lib/explorer/chain.ex	16	19	84.21%
apps/explorer/lib/explorer/chain/block/reward.ex	5	9	55.56%

Files with Coverage Reduction	New Missed Lines	%
apps/block_scout_web/lib/block_scout_web/controllers/chain/market_history_chart_controller.ex	2	71.43%

Totals
Change from base Build 43c5f8fd-0d8e-4455-831a-a15f9933ffea:	-0.03%
Covered Lines:	5351
Relevant Lines:	7114

---

💛 - Coveralls

[vbaranov]

@ayrat555 I found a way how to improve performance of the page for validators without limits:

UPDATE 2019-12-12
I found a way how to increase the performance of the validators' address' page even without limiting the number of taking to account rewards. The idea is to get the range of blocks where transactions found for this page of the transactions' list in the pagination and show rewards, that are in the block's range. Even despite that fact that page will wait retrieving of this blocks' range first to proceed with rewards query, page works dramatically faster.

need to be reviewed again