-
Notifications
You must be signed in to change notification settings - Fork 494
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
Add lazy_lsru_download flag to compute spec and automatically make decision about lazy SLRU download #11012
Open
knizhnik
wants to merge
4
commits into
main
Choose a base branch
from
on_demand_download_guc
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+108
−34
Open
Add lazy_lsru_download flag to compute spec and automatically make decision about lazy SLRU download #11012
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: The total size is already tracked in
SlruSegmentBuilder
. You could makeSlruSegmentBuilder::finish
return it instead of tracking it here again.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.
Just think more about @hlinnaka second proposal - always include last segment of SLRU in basebackup.
My first though was that it is not so good idea, because in most cases Postgres doesn't need to access CLOG - it relies either on record hints, either on snapshot horizon.
But then I understand that to be able to update SRLU, we in any case need first to read updated segment (in most cases - last segment). So it may be really useful and reduce real startup time.
But then I recognised that there is not efficient way in current KV storage API to locate last segment (@VladLazar please correct me). So to locate last segment we in any case have to iterate through all segments. Which makes this optimization senseless.
My second thought was that there are many other pages which will be requested by backend in any case - some tables from system catalog. But we do not have such optimisation now and access this catalog pages in usual way.
Then I return back to first @hlinnaka proposal: always use on-demand download. If we are doing it for much more pages of system catalog, then doing it for few SLRU segments should not somehow significantly affect startup time.
Also, may be my first thought was also not so stupid: yes we need to download SLRU segment in order to update it. But we need to update SLRU if we perform some updates (write transaction). But most queries to the database are read-only, do not need XID and do not write something to SLRU. So using lazy download in this we can really reduce startup time even for small SLRUs (not sure how noticeable it will be).
So @hlinnaka , @VladLazar what do you think about removing all this logic with lazy SLRU download threshold and use it always (when it is enabled by control plane? Also may be remove it from tenant config?
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.
We don't have to iterate through all segments as far as I see. Let's consider a single slru kind for brevity:
so worst case we need two vectored reads (capped at 16 keys currently).
So overall, it adds up to 4 reads per slru kind.
I don't have a lot of context as to when SLRU is needed inside the compute, but if total SLRU size is small why do extra round trips (PS <-> compute API only allows for one segment at a time)? Also, I think we should keep it as a tenant config to make it easier to test (both in regression tests and staging).
I just checked the on-demand slru segment download logic on the pageserver. It queries pages one by one, instead of using the vectorized API. We should update this regardless.
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.
Thank you!
I forget about SLRU directory.
Using this directory getting the last segment is really trivial operation.
But still not sure whether it make sense to include in basebackup just last segment or better to lazily download all segments.