YSQL: Cache sys catalog read request on local t-server side #10821
Assignees
Labels
area/ysql
Yugabyte SQL (YSQL)
kind/enhancement
This is an enhancement of an existing feature
priority/critical
Critical issue
Comments
d-uspenskiy
added
the
kind/enhancement
|
Related to #11997 |
pkj415
pushed a commit
to pkj415/yugabyte-db
that referenced
this issue
Jul 19, 2022
…er side [WIP] Summary: TBD Test Plan: Jenkins Reviewers: sergei, mihnea, jason Subscribers: yql, bogdan Differential Revision: https://phabricator.dev.yugabyte.com/D17824
yugabyte-ci
added
priority/critical
d-uspenskiy
added a commit
that referenced
this issue
Nov 22, 2022
Summary: On cache refresh YSQL sends RPC to a master which reads multiple system tables. Nowadays they are: - pg_database - pg_class - pg_attribute - pg_opclass - pg_am - pg_amproc - pg_index - pg_rewrite - pg_attrdef - pg_constraint - pg_partitioned_table - pg_type - pg_namespace - pg_authid All active postgres connections send the same RPC to master on cache refresh. As long as YSQL sends RPC via local t-server proxy it is reasonable to cache the response on this RPC on local t-server and reuse data from cache instead of resending same RPC to a master over and over again (i.e. 1 request per each active connection). `PgResponseCache` is the `LRUCache` which stored in the `PgClientService`. Key in this cache is a text representation of RPC request. But special field in this request must be nullified (cleared out) first. Because the value of this field is unique for each request and it doesn't affect the response. This field is `PgsqlReadRequestPB::stmt_id`. Also cacheable request must have additional field which will contains info about system catalog version. Because in case of catalog changes it is necessary to send new request to a master instead of using data from the local t-server cache as this data is outdated. **Note:** Only request which preloads the sys catalog is cacheable now. Requests which loads sys catalog records on-demand are not cacheable. The necessity of caching these requests will be estimated in future. Test Plan: Jenkins ``` ./yb_build.sh --gtest_filter PgCatalogPerfTest.ResponseCacheEfficiency ``` Reviewers: mihnea, jason, myang, sergei Reviewed By: myang, sergei Subscribers: plee, smishra, yql, bogdan Differential Revision: https://phabricator.dev.yugabyte.com/D17824
|
If there is still backport work pending for stable releases, can we leave this open and tag with 2.14 / 2.16 Backport Required @tverona1 @d-uspenskiy I understand this is not yet ported to stable for those asking for tserver catalog caching |
d-uspenskiy
added a commit
that referenced
this issue
Dec 6, 2022
… t-server side Summary: On cache refresh YSQL sends RPC to a master which reads multiple system tables. Nowadays they are: - pg_database - pg_class - pg_attribute - pg_opclass - pg_am - pg_amproc - pg_index - pg_rewrite - pg_attrdef - pg_constraint - pg_partitioned_table - pg_type - pg_namespace - pg_authid All active postgres connections send the same RPC to master on cache refresh. As long as YSQL sends RPC via local t-server proxy it is reasonable to cache the response on this RPC on local t-server and reuse data from cache instead of resending same RPC to a master over and over again (i.e. 1 request per each active connection). `PgResponseCache` is the `LRUCache` which stored in the `PgClientService`. Key in this cache is a text representation of RPC request. But special field in this request must be nullified (cleared out) first. Because the value of this field is unique for each request and it doesn't affect the response. This field is `PgsqlReadRequestPB::stmt_id`. Also cacheable request must have additional field which will contains info about system catalog version. Because in case of catalog changes it is necessary to send new request to a master instead of using data from the local t-server cache as this data is outdated. **Note:** Only request which preloads the sys catalog is cacheable now. Requests which loads sys catalog records on-demand are not cacheable. The necessity of caching these requests will be estimated in future. Original commit: 7672a48 / D17824 Test Plan: Jenkins: rebase: 2.16 ``` ./yb_build.sh --gtest_filter PgCatalogPerfTest.ResponseCacheEfficiency ``` Reviewers: jason, sergei, mihnea, myang Reviewed By: myang Subscribers: smishra, plee, mihnea, yql, bogdan Differential Revision: https://phabricator.dev.yugabyte.com/D21452
jayant07-yb
pushed a commit
to jayant07-yb/yugabyte-db
that referenced
this issue
Dec 7, 2022
…er side Summary: On cache refresh YSQL sends RPC to a master which reads multiple system tables. Nowadays they are: - pg_database - pg_class - pg_attribute - pg_opclass - pg_am - pg_amproc - pg_index - pg_rewrite - pg_attrdef - pg_constraint - pg_partitioned_table - pg_type - pg_namespace - pg_authid All active postgres connections send the same RPC to master on cache refresh. As long as YSQL sends RPC via local t-server proxy it is reasonable to cache the response on this RPC on local t-server and reuse data from cache instead of resending same RPC to a master over and over again (i.e. 1 request per each active connection). `PgResponseCache` is the `LRUCache` which stored in the `PgClientService`. Key in this cache is a text representation of RPC request. But special field in this request must be nullified (cleared out) first. Because the value of this field is unique for each request and it doesn't affect the response. This field is `PgsqlReadRequestPB::stmt_id`. Also cacheable request must have additional field which will contains info about system catalog version. Because in case of catalog changes it is necessary to send new request to a master instead of using data from the local t-server cache as this data is outdated. **Note:** Only request which preloads the sys catalog is cacheable now. Requests which loads sys catalog records on-demand are not cacheable. The necessity of caching these requests will be estimated in future. Test Plan: Jenkins ``` ./yb_build.sh --gtest_filter PgCatalogPerfTest.ResponseCacheEfficiency ``` Reviewers: mihnea, jason, myang, sergei Reviewed By: myang, sergei Subscribers: plee, smishra, yql, bogdan Differential Revision: https://phabricator.dev.yugabyte.com/D17824
|
@sharkberto is this still planning on being backported to 2.14? |
|
@jameshartig Not planning to backport to 2.14 - Sorry for any confusion |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Jira Link: DB-3251
After landing the #9936 it will be possible to cache sys catalog read request on a local t-server side to improve postgres catalog cache refresh process.
The text was updated successfully, but these errors were encountered: