Re: Dataframes: PrunedFilteredScan without Spark Side Filtering

Please do. On Wed, Oct 7, 2015 at 9:49 AM, Russell Spitzer wrote: > Should I make up a new ticket for this? Or is there something already > underway? > > On Mon, Oct 5, 2015 at 4:31 PM Russell Spitzer > wrote: > >> That sounds fine to me,

Re: Dataframes: PrunedFilteredScan without Spark Side Filtering

Should I make up a new ticket for this? Or is there something already underway? On Mon, Oct 5, 2015 at 4:31 PM Russell Spitzer wrote: > That sounds fine to me, we already do the filtering so populating that > field would be pretty simple. > > On Sun, Sep 27, 2015 at

Re: Dataframes: PrunedFilteredScan without Spark Side Filtering

That sounds fine to me, we already do the filtering so populating that field would be pretty simple. On Sun, Sep 27, 2015 at 2:08 PM Michael Armbrust wrote: > We have to try and maintain binary compatibility here, so probably the > easiest thing to do here would be to

Re: Dataframes: PrunedFilteredScan without Spark Side Filtering

We have to try and maintain binary compatibility here, so probably the easiest thing to do here would be to add a method to the class. Perhaps something like: def unhandledFilters(filters: Array[Filter]): Array[Filter] = filters By default, this could return all filters so behavior would remain

Dataframes: PrunedFilteredScan without Spark Side Filtering

Hi! First time poster, long time reader. I'm wondering if there is a way to let cataylst know that it doesn't need to repeat a filter on the spark side after a filter has been applied by the Source Implementing PrunedFilterScan. This is for a usecase in which we except a filter on a