Maintain materialized view data status. #501
Merged
Conversation
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
avamingli
force-pushed
the
mv_data
branch
9 times, most recently
from
71866fd to
ec60ec5
Compare
|
Enabled this feature in SingleNode mode. |
A materialized view's data could be seen as up to date with base tables if there are no writable operations since last Refresh of the view. If one of base tables in the query tree of a materailied view is modified, the view data is not up to date. And we could not use it to answer query. This commit maintain the data satus of a materialized view and it applies to normal materialized view, IVM with defer refresh. IVM with immediately refresh is always up to date. When a base table has writable operation, we try to update view data status as: - 'u'(up to date): Create Materialized View Refresh - 'e'(expired): Update base tables Delete base tables Refresh With No Data Truncate base tables Create Materialized View With No Data - 'i'(insert only): Insert info base tables Copy From Copy From on Segments - 'r'(up to date but reorganized): Cluster base tables Vacuum Full base tables Insert, Update, Delete, Copy From operations take effect if the actual affected rows > 0, ex: insert into t1 select * from t2; We don't need to update view if t2 has zero rows. The real status will be decided both by current and the status we try to mark as.Ex: we try to mark insert only on a expired status, it will not success. This doesn't work on utility mode, if user modified data in that mode, should refresh views if want to use it to answer query. AQUMV could use normal materialized views after this commit. Authored-by: Zhang Mingli [email protected]
my-ship-it
reviewed
Jul 11, 2024
my-ship-it
approved these changes
Jul 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A materialized view's data could be seen as up to date with base tables if there is no writable operations since last Refresh of the view.
If one of base tables in the query tree of a materailied view is modified, the view data is not up to date. And we could not use it to answer query.
This commit maintain the data satus of a materialized view and it applies to normal materialized view, IVM with defer refresh. IVM with immediately refresh is always up to date.
When a base table has writable operation, we try to update view data status as:
'u'(up to date):
'e'(expired):
'i'(insert only):
'r'(up to date but reorganized):
Insert, Update, Delete, Copy From operations take effect if the actual affected rows > 0, ex:
sql insert into t1 select * from t2;We don't need to update view if t2 has zero rows.
The real status will be decided both by current and the status we try to mark as.Ex: we try to mark insert only on a expired status, it will not success.
This doesn't work on utility mode, if user modified data in that mode, should refresh views if want to use it to answer query.
AQUMV could use normal materialized views after this commit.
Authored-by: Zhang Mingli [email protected]
fix #ISSUE_Number
Change logs
Describe your change clearly, including what problem is being solved or what feature is being added.
If it has some breaking backward or forward compatibility, please clary.
Why are the changes needed?
Describe why the changes are necessary.
Does this PR introduce any user-facing change?
If yes, please clarify the previous behavior and the change this PR proposes.
How was this patch tested?
Please detail how the changes were tested, including manual tests and any relevant unit or integration tests.
Contributor's Checklist
Here are some reminders and checklists before/when submitting your pull request, please check them:
make installcheckmake -C src/test installcheck-cbdb-parallelcloudberrydb/devteam for review and approval when your PR is ready🥳