If You’re Not Collecting Statistics on Your Dictionary Tables, Do It. Now. - comment by clakshminarasu

Hi Carrie
I have this situation where my team writes views (for simplicity, we call them reusable views) which often uses joins based on ID fields and current indicators.
Then comes the consumer views which are built on top of these reusable views. Again consumers build their logical data extraction on top of consumer views for their dashboarding and charting purposes.
when I see the explain plan of our consumer views or reusable views, I see optimiser uses multiple levels of joins on current indicators. But these indicators are hardly containing 'y' or 'n' values. They mostly indicate product or merge joins. When we we pass this for diagnostic stats, we see the recommendation for collecting stats on these indicator columns too.
My question is - Is it worth collecting stats on tables for such indicator columns which ranges from few MBs to few GBs? We already have collected stats on joining ID fields which is also a NUPI.
Another question -Why does optimiser build merge or product join step based on indicator fields when we nest reusable views into consumer views?
 
Thanks,
Lakshminarasu