Uh oh!
There was an error while loading. Please reload this page.
[SPARK-3645][SQL] Makes table caching eager by default and adds syntax for lazy caching - #2513
[SPARK-3645][SQL] Makes table caching eager by default and adds syntax for lazy caching#2513liancheng wants to merge 1 commit into
Conversation
SparkQA
commented
Sep 24, 2014
QA tests have started for PR 2513 at commit
|
SparkQA
commented
Sep 24, 2014
QA tests have finished for PR 2513 at commit
|
SparkQA
commented
Sep 24, 2014
Test PASSed. |
SparkQA
commented
Sep 24, 2014
QA tests have started for PR 2513 at commit
|
SparkQA
commented
Sep 24, 2014
QA tests have finished for PR 2513 at commit
|
SparkQA
commented
Sep 24, 2014
Test PASSed. |
There was a problem hiding this comment.
This is kind of a nit, but I talked to @aarondav and we are thinking that CACHE TABLE LAZY might be a little more consistent. The reasoning being that CACHE is really the most important verb here and so should go first. This is similar to INSERT INTO TABLE vs INSERT OVERWRITE TABLE.
There was a problem hiding this comment.
Agree, I wasn't very sure about the syntax either when add this.
liancheng
commented
Oct 2, 2014
Updated, replaced |
SparkQA
commented
Oct 2, 2014
QA tests have started for PR 2513 at commit
|
SparkQA
commented
Oct 2, 2014
QA tests have finished for PR 2513 at commit
|
AmplabJenkins
commented
Oct 2, 2014
Test PASSed. |
liancheng
commented
Oct 4, 2014
Rebased to the master, with the new |
SparkQA
commented
Oct 4, 2014
QA tests have started for PR 2513 at commit
|
SparkQA
commented
Oct 4, 2014
QA tests have finished for PR 2513 at commit
|
AmplabJenkins
commented
Oct 4, 2014
Test PASSed. |
There was a problem hiding this comment.
Added keyword LAZY and sorted all the keywords in alphabetical order here. This list was once sorted but broken later.
marmbrus
commented
Oct 6, 2014
I'm going to merge this. Feel free to clean up minor ";" issue as part of the other parser refactoring you are doing. Thanks :) |
There was a problem hiding this comment.
@marmbrus Forgot to confirm this with you: default value of the blocking argument is true in RDD.unpersist(), I changed the default value here to keep the semantics consistent. This also makes testing more easily (I added assertions to check RDD materialization, non-blocking unpersisting introduces some subtleties). Did you intend to use non-blocking unpersisting here?
There was a problem hiding this comment.
No, I mistakenly though that was the default. We should match the original semantics.
Although lazy caching for in-memory table seems consistent with the
RDD.cache()API, it's relatively confusing for users who mainly work with SQL and not familiar with Spark internals. TheCACHE TABLE t; SELECT COUNT(*) FROM t;pattern is also commonly seen just to ensure predictable performance.This PR makes both the
CACHE TABLE t [AS SELECT ...]statement and theSQLContext.cacheTable()API eager by default, and adds a newCACHE LAZY TABLE t [AS SELECT ...]syntax to provide lazy in-memory table caching.Also, took the chance to make some refactoring:
CacheCommandandCacheTableAsSelectCommandare now merged and renamed toCacheTableCommandsince the former is strictly a special case of the latter. A newUncacheTableCommandis added for theUNCACHE TABLE tstatement.