You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iceberg.apache.org by Steven Wu <st...@gmail.com> on 2022/08/23 16:43:51 UTC

Question for view and secondary index

I have a question related to the view feature for this scenario. Physical
table is a byte[] column + some promoted columns. We create a view table
that explodes the byte[] column to many columns in the logical view
(probably via some UDF function). If the physical table has a secondary
index (say bloom filter) on a promoted column, the bloom filter would still
be useful for the view table, right?

Thanks,
Steven

Re: Question for view and secondary index

Posted by Ryan Blue <bl...@tabular.io>.
Yes, that's probably right. Views get expanded to a logical plan instead of
a simple scan. So what typically happens is you parse the original SQL,
then parse the view SQL and insert it into the first plan to get a combined
plan. That combined plan is what gets optimized, so your filters on the
view likely get pushed all the way down into the scan inside the view.

On Tue, Aug 23, 2022 at 9:44 AM Steven Wu <st...@gmail.com> wrote:

>
> I have a question related to the view feature for this scenario. Physical
> table is a byte[] column + some promoted columns. We create a view table
> that explodes the byte[] column to many columns in the logical view
> (probably via some UDF function). If the physical table has a secondary
> index (say bloom filter) on a promoted column, the bloom filter would still
> be useful for the view table, right?
>
> Thanks,
> Steven
>


-- 
Ryan Blue
Tabular