Thanks for digging, Arun. That's super helpful. Doing that check for a view is really a bug as it's not traversing the correct link anyway. If you have a table -> v1 -> v2, it won't prevent you from dropping v1. It's really meant to check whether or not you're trying to drop a table that has views. Based on the way Phoenix manages views, I can't think of any problem in letting v1 be dropped anyway.
File a bug, ideally with a patch that conditionally does the findChildViews() only when a table (as opposed to a view) is being dropped (i.e. in doDropTable check tableType == PTableType.TABLE and only then call that method). Also, if you have a chance, file a separate JIRA for maintaining the link in both directions - that's something we should consider too. Thanks, James On Wed, Jun 17, 2015 at 4:26 PM, Arun Kumaran Sabtharishi <[email protected]> wrote: > James, > > We dug deeper and found that the time is spent in the > MetaDataEndPointImpl.findChildViews() method. It runs a scan on the > SYSTEM.CATALOG table looking for the link record. Since the link record is > in the format CHILD-PARENT, it has to scan the entire table to find the > parent suffix. > > In our scenario, we only have views that references a single table.(We don't > have view that references views). As a workaround, is it safe to simply run > delete from SYSTEM.CATALOG where table_name = 'MY_VIEW'? Would there be any > side effects in doing this? > > For the long term solution, we can write two link records, the existing > CHILD-PARENT and a new PARENT-CHILD so that the findChildViews() method can > use a key range scan. > > Thanks, > Arun
