[CALCITE-2828] Fix VolcanoPlanner.validate() to handle cost propagati…#1054
Open
StevenMPhillips wants to merge 1 commit intoapache:mainfrom
Open
[CALCITE-2828] Fix VolcanoPlanner.validate() to handle cost propagati…#1054StevenMPhillips wants to merge 1 commit intoapache:mainfrom
StevenMPhillips wants to merge 1 commit intoapache:mainfrom
Conversation
…on properly When getCost(rel) is called, a node's nonCumulativeCost() is computed. When using CachingRelMetadataProvider is used, metadata is cached (rowCount, cost, etc.) for future use. In order to make sure that we do not use stale metadata, each RelOptPlanner provides getRelMetadataTimestamp(rel) which is used to invalidate the cache (if the cached entry has timestamp != getRelMetadataTimestamp(rel), it is not used. The problem in this case was due to the fact that VolcanoPlanner uses the rel's current RelSubset's timestamp as getRelMetadataTimestamp(). Since a rel can belong to multiple RelSubset, this results in inconsistent cache hits/misses. For example, if a rel belongs to RelSubset#1 and RelSubset#2 with relMetadataTimestamp of 1 and 2, respectively. If rel happens to update its cost with RelSubset#1 first, then the cache will be updated with timestamp 1 so when the same rel in RelSubset#2's context try to look up its metadata, it will fail. This results in inefficient use of the cache. The main problem occurs when we get incorrect cache hits (e.g. previous iteration of metadata query on RelSubset#2 populated the cache with timestamp 2, but later in the context of RelSubset#1, we think there is a valid cache and use the stale metadata). Change-Id: Iefb630f5813ba497b7fbc0144c8fd6050e59b1a3
hsyuan
reviewed
Mar 9, 2019
Member
hsyuan
left a comment
hsyuan
left a comment
There was a problem hiding this comment.
Hi @StevenMPhillips, can you add a test case for this change?
danny0405
force-pushed
the
master
branch
2 times, most recently
from
80f411d to
ca27fe9
Compare
vlsi
force-pushed
the
master
branch
2 times, most recently
from
49cb002 to
8768a23
Compare
julianhyde
force-pushed
the
main
branch
2 times, most recently
from
8a5cf83 to
cf7f71b
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
…on properly
When getCost(rel) is called, a node's nonCumulativeCost() is computed. When using CachingRelMetadataProvider is used, metadata is cached (rowCount, cost, etc.) for future use. In order to make sure that we do not use stale metadata, each RelOptPlanner provides getRelMetadataTimestamp(rel) which is used to invalidate the cache (if the cached entry has timestamp != getRelMetadataTimestamp(rel), it is not used.
The problem in this case was due to the fact that VolcanoPlanner uses the rel's current RelSubset's timestamp as getRelMetadataTimestamp(). Since a rel can belong to multiple RelSubset, this results in inconsistent cache hits/misses. For example, if a rel belongs to RelSubset#1 and RelSubset#2 with relMetadataTimestamp of 1 and 2, respectively. If rel happens to update its cost with RelSubset#1 first, then the cache will be updated with timestamp 1 so when the same rel in RelSubset#2's context try to look up its metadata, it will fail. This results in inefficient use of the cache. The main problem occurs when we get incorrect cache hits (e.g. previous iteration of metadata query on RelSubset#2 populated the cache with timestamp 2, but later in the context of RelSubset#1, we think there is a valid cache and use the stale metadata).
Change-Id: Iefb630f5813ba497b7fbc0144c8fd6050e59b1a3