[ 
https://issues.apache.org/jira/browse/PHOENIX-5002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670480#comment-16670480
 ] 

Vincent Poon commented on PHOENIX-5002:
---------------------------------------

The IndexMaintainer is only set on the mutation if there are indexes, so that's 
how those checks in PhoenixIndexCodec are working.

Using the disable flag is complicated by the fact that we would need to flip it 
on every region, so we'd need some sort of broadcast that is synchronous.  
Seems difficult to get right, unless you go the remove/add coproc route which 
as Geoffrey pointed out had to re-open each region.  Which is probably why it 
was implemented in its current fashion...

I guess the current implementation piggyback's on the existing metadata change 
framework, wherein changes to table metadata get picked up by clients, which 
then set the index maintainer...

> Don't load or disable Indexer coprocessor for non-indexed tables
> ----------------------------------------------------------------
>
>                 Key: PHOENIX-5002
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5002
>             Project: Phoenix
>          Issue Type: Improvement
>    Affects Versions: 4.14.1
>            Reporter: Vincent Poon
>            Priority: Major
>
> It seems the Indexer coprocessor is loaded for tables even if they have no 
> indexes.
> There is some overhead such as write locking within Phoenix - we should 
> investigate whether we can avoid loading the Indexer coproc or disable it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to