-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Autovacuum crypto_transfer, token_transfer, and transaction #1825
Conversation
…n_transfer Signed-off-by: Xin Li <xin.li@hedera.com>
Codecov Report
@@ Coverage Diff @@
## master #1825 +/- ##
============================================
- Coverage 87.37% 85.41% -1.97%
+ Complexity 1743 378 -1365
============================================
Files 315 135 -180
Lines 7691 3859 -3832
Branches 735 379 -356
============================================
- Hits 6720 3296 -3424
+ Misses 744 509 -235
+ Partials 227 54 -173
Continue to review full report at Codecov.
|
…ount_id, consensus_ns) Signed-off-by: Xin Li <xin.li@hedera.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Do we need to consider doing account_balance as well?
Checked The consensus_timestamp query will not benefit much from index only scan since we just look for one consensus_timestamp and at most pg just has to spend an extra trip to make sure the corresponding index's data in the page is not stale. The other queries always select the balance and balance is not in any indexes, so they are not index-only scans. So vacuuming these tables more frequently won't speed up our queries thus we shouldn't do it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, nit suggestion based on your preference.
Also is transactions not a huge insert only table.
Would some queries such as account and time range benefit from a vacuum more often?
-- autovacuum insert-only tables more frequently to ensure most pages are visible for index-only scans | ||
-- prior to postgresql 13, this can be achieved by configuring a more aggressive anti-wraparound autovacuum | ||
------------------- | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit:
\set autovacuum_freeze_max_age '100000'
\set autovacuum_freeze_table_age '100000'
Or if there's value to configurability you can add it as property in the application.yaml
under spring.flyway.placeholders
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changed both to repeatable migrations and added properties to spring.flyway.placeholders
We'll be bumping our TimescaleDB chart to use PostgreSQL 13 soon and our timescale.com SaaS uses PostgreSQL 13. Can you update the schema v2 stuff to use the newer pg13 approach you mention? |
definitely. the pg13 new insert-only table autovacuum mechanism will be more efficient. |
Signed-off-by: Xin Li <xin.li@hedera.com>
Signed-off-by: Xin Li <xin.li@hedera.com>
…Mount = true - change db migration to be repeatable Signed-off-by: Xin Li <xin.li@hedera.com>
401e099
Signed-off-by: Xin Li <xin.li@hedera.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Signed-off-by: Xin Li <xin.li@hedera.com>
SonarCloud Quality Gate failed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
- configure more frequent anti-wraparound autovacuum for crypto_transfer, token_transfer, and transaction for pg 9.6 - configure more frequent insert-only autovacuum for crypto_transfer, token_transfer, and transaction for pg 13 - upgrade to timescale/timescaledb-ha:pg13-ts2.2-latest - increase shm size for timescaledb container Signed-off-by: Xin Li <xin.li@hedera.com> Signed-off-by: Ian Jungmann <ian.jungmann@hedera.com>
Detailed description:
crypto_transfer
,token_transfer
, andtransaction
for pg 9.6crypto_transfer
,token_transfer
, andtransaction
for pg 13Which issue(s) this PR fixes:
Fixes #1780
Fixes #1849
Special notes for your reviewer:
Criteria for the tables to enable more frequent autovacuum:
For pg 9.6
Reference doc: https://www.postgresql.org/docs/9.6/routine-vacuuming.html section 24.1.5
autovacuum_freeze_max_age
can't be set lower than 100,000, mainnet postgresql tx id grows at around 60,000/dayautovacuum_freeze_table_age
is needed otherwise postgresql will use the global parametervacuum_freeze_table_age
which is 150,000,000. then the autovacuum ends up not freezing any pages and running forever since the table age won't changeautovacuum_freeze_min_age = 0
is aggressive, freezes all pages at the time of acutovacuum scanlog_autovacuum_min_duration = 0
turns on logging of autovacuum of the tableConcerns:
For timescaledb with pg13
pg 13 introduces a new method to configure autovacuum for insert-only tables:
autovacuum_vacuum_insert_threshold
, default to 1000autovacuum_vacuum_insert_scale_factor
, default to 0.2autovacuum will run when the number of inserts exceeds
autovacuum_vacuum_insert_threshold + reltuples * autovacuum_vacuum_insert_scale_factor
for a table since last autovacuum.reltuples
is the approximate table size.The values set for table
crypto_transfer
andtransaction
are based on the current daily transaction volume in mainnet.token_transfer
has very few transactions (less than 6k in the past week) so the value will not have a real impact on performance and we should adjust it when the traffic grows.For timescaledb, autovacuum will only scan the current chunk, which is more efficient.
Checklist