[jira] [Updated] (PHOENIX-4989) Include disruptor jar in shaded dependency

[ https://issues.apache.org/jira/browse/PHOENIX-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aman Poonia updated PHOENIX-4989: - Fix Version/s: 4.14.1 > Include disruptor jar in shaded dependency >

[jira] [Updated] (PHOENIX-4764) Cleanup metadata of child views for a base table that has been dropped

[ https://issues.apache.org/jira/browse/PHOENIX-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR updated PHOENIX-4764: --- Attachment: PHOENIX-4764.master.0004.patch > Cleanup metadata of child views for a base

[VOTE] Release of Apache Phoenix 4.14.1 RC0

Hello Everyone, This is a call for a vote on Apache Phoenix 4.14.1 RC0. This is a patch release of Phoenix 4.14 and is compatible with Apache HBase 0.98, 1.1, 1.2, 1.3, 1.4. The release includes both a source-only release and a convenience binary release for each supported HBase version. This

Re: Regarding the Secondary Index write path

Abhishek, You might want to check out Vincent Poon's excellent presentation at this year's PhoenixCon about recent changes over the past couple of years to the index pipeline. https://www.youtube.com/watch?v=VBONDM7sD40 One of those changes is the one you observed. Global mutable index writes

[jira] [Created] (PHOENIX-5000) Make SecureUserConnectionsTest as Integration test

Karan Mehta created PHOENIX-5000: Summary: Make SecureUserConnectionsTest as Integration test Key: PHOENIX-5000 URL: https://issues.apache.org/jira/browse/PHOENIX-5000 Project: Phoenix Issue

[jira] [Updated] (PHOENIX-4989) Include disruptor jar in shaded dependency

[ https://issues.apache.org/jira/browse/PHOENIX-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-4989: -- Fix Version/s: (was: 4.14.1) 4.15.0 4.14.2 >

Re: Regarding the Secondary Index write path

If the table has no indexes, the Indexer coprocessor won't be loaded. As for your original question, the answer is a little nuanced. For Phoenix 4.14+: The index updates are calculated in preBatchMutate, and the index updates are written in postBatchMutate. So from HRegion#doMiniBatchMutation,

Re: Regarding the Secondary Index write path

Thanks Geoffrey for confirming that. Will go through that presentation. I have a follow-up question though, Let’s say if a table does not have any indexes on it, will these co-processors still be triggered and try to calculate index updates, since these are loaded by default for any table that is

[jira] [Updated] (PHOENIX-5000) Make SecureUserConnectionsTest as Integration test

[ https://issues.apache.org/jira/browse/PHOENIX-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karan Mehta updated PHOENIX-5000: - Attachment: PHOENIX-5000.master.001.patch > Make SecureUserConnectionsTest as Integration test

[jira] [Created] (PHOENIX-5001) Don't issue deletes for ALTER INDEX REBUILD

Vincent Poon created PHOENIX-5001: - Summary: Don't issue deletes for ALTER INDEX REBUILD Key: PHOENIX-5001 URL: https://issues.apache.org/jira/browse/PHOENIX-5001 Project: Phoenix Issue

Re: Regarding the Secondary Index write path

Thanks Vincent. Just to clarify, if I create a table through Phoenix and check the describe on the hbase table, I see that the Indexer co-processor is loaded with the table. Is there some code that loads only the required co-processors when there is an Observer event? Coming back to the sequence

[jira] [Updated] (PHOENIX-4830) order by primary key desc return wrong results

[ https://issues.apache.org/jira/browse/PHOENIX-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Cang updated PHOENIX-4830: - Attachment: PHOENIX-4830-4.x-HBase-1.3.007.patch > order by primary key desc return wrong results >

[jira] [Assigned] (PHOENIX-5001) Don't issue deletes for ALTER INDEX REBUILD

[ https://issues.apache.org/jira/browse/PHOENIX-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey Jacoby reassigned PHOENIX-5001: Assignee: Geoffrey Jacoby > Don't issue deletes for ALTER INDEX REBUILD >

[jira] [Updated] (PHOENIX-4764) Cleanup metadata of child views for a base table that has been dropped

[ https://issues.apache.org/jira/browse/PHOENIX-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR updated PHOENIX-4764: --- Attachment: PHOENIX-4764.master.0005.patch > Cleanup metadata of child views for a base

[jira] [Updated] (PHOENIX-4891) An index should inherit UPDATE_CACHE_FREQUENCY setting from parent table

[ https://issues.apache.org/jira/browse/PHOENIX-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-4891: -- Attachment: PHOENIX-4891-4.x-HBase-1.3.patch > An index should inherit

[jira] [Updated] (PHOENIX-4764) Cleanup metadata of child views for a base table that has been dropped

[ https://issues.apache.org/jira/browse/PHOENIX-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR updated PHOENIX-4764: --- Attachment: PHOENIX-4764.master.0006.patch > Cleanup metadata of child views for a base

[jira] [Updated] (PHOENIX-4764) Cleanup metadata of child views for a base table that has been dropped

[ https://issues.apache.org/jira/browse/PHOENIX-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR updated PHOENIX-4764: --- Attachment: PHOENIX-4764.4.x-HBase-1.4.0005.patch > Cleanup metadata of child views for a

[jira] [Created] (PHOENIX-5002) Don't load Indexer coprocessor for non-indexed tables

Vincent Poon created PHOENIX-5002: - Summary: Don't load Indexer coprocessor for non-indexed tables Key: PHOENIX-5002 URL: https://issues.apache.org/jira/browse/PHOENIX-5002 Project: Phoenix

Re: Regarding the Secondary Index write path

Looks like you're right, the Indexer is loaded for all base tables. I got confused with the case where the Indexer coproc is not loaded for *index* tables. I wonder what the overhead is like for having that. It does seem from the code like loading it was intentional, as there are lines like this