[ https://issues.apache.org/jira/browse/SPARK-11661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15075690#comment-15075690 ]
Russell Alexander Spitzer edited comment on SPARK-11661 at 12/31/15 3:44 AM: ----------------------------------------------------------------------------- This seems to have a slightly unintended consequence in the explain dialogue. It basically makes it seem as if a source is always pushing down all of the filters (even those it cannot handle) This can have a confusing effect (I kept checking my code to see where I had broken something :D ) {code: title="Query plan for source where nothing is handled by C* Source"} Filter ((((a#71 = 1) && (b#72 = 2)) && (c#73 = 1)) && (e#75 = 1)) +- Scan org.apache.spark.sql.cassandra.CassandraSourceRelation@4b9cf75c[a#71,b#72,c#73,d#74,e#75,f#76,g#77,h#78] PushedFilters: [EqualTo(a,1), EqualTo(b,2), EqualTo(c,1), EqualTo(e,1)] {code} Although the tell tale "Filter" step is present my first instinct would tell me that the underlying source relation is using all of those filters. {code: title="Query plan for source where *everything* is handled by C* Source"} Scan org.apache.spark.sql.cassandra.CassandraSourceRelation@55d4456c[a#79,b#80,c#81,d#82,e#83,f#84,g#85,h#86] PushedFilters: [EqualTo(a,1), EqualTo(b,2), EqualTo(c,1), EqualTo(e,1)] {code} I think this would be much clearer if we changed the metadata key to "HandledFilters" and only listed those handled fully by the underlying source. wdyt? was (Author: rspitzer): This seems to have a slightly unintended consequence in the explain dialogue. It basically makes it seem as if a source is always pushing down all of the filters (even those it cannot handle) This can have a confusing effect (I kept checking my code to see where I had broken something :D ) {code: Title="Query plan for source where nothing is handled by C* Source"} Filter ((((a#71 = 1) && (b#72 = 2)) && (c#73 = 1)) && (e#75 = 1)) +- Scan org.apache.spark.sql.cassandra.CassandraSourceRelation@4b9cf75c[a#71,b#72,c#73,d#74,e#75,f#76,g#77,h#78] PushedFilters: [EqualTo(a,1), EqualTo(b,2), EqualTo(c,1), EqualTo(e,1)] {code} Although the tell tale "Filter" step is present my first instinct would tell me that the underlying source relation is using all of those filters. {code: Title="Query plan for source where *everything* is handled by C* Source"} Scan org.apache.spark.sql.cassandra.CassandraSourceRelation@55d4456c[a#79,b#80,c#81,d#82,e#83,f#84,g#85,h#86] PushedFilters: [EqualTo(a,1), EqualTo(b,2), EqualTo(c,1), EqualTo(e,1)] {code} I think this would be much clearer if we changed the metadata key to "HandledFilters" and only listed those handled fully by the underlying source. wdyt? > We should still pushdown filters returned by a data source's unhandledFilters > ----------------------------------------------------------------------------- > > Key: SPARK-11661 > URL: https://issues.apache.org/jira/browse/SPARK-11661 > Project: Spark > Issue Type: Bug > Components: SQL > Reporter: Yin Huai > Assignee: Yin Huai > Priority: Blocker > Fix For: 1.6.0 > > > We added unhandledFilters interface to SPARK-10978. So, a data source has a > chance to let Spark SQL know that for those returned filters, it is possible > that the data source will not apply them to every row. So, Spark SQL should > use a Filter operator to evaluate those filters. However, if a filter is a > part of returned unhandledFilters, we should still push it down. For example, > our internal data sources do not override this method, if we do not push down > those filters, we are actually turning off the filter pushdown feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org For additional commands, e-mail: issues-h...@spark.apache.org