phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4023) Handle drop of shared index when UPDATE_CACHE_FREQUENCY is set
Date Sat, 15 Jul 2017 01:13:00 GMT

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

James Taylor commented on PHOENIX-4023:
---------------------------------------

Definitively figuring out the max of UPDATE_CACHE_FREQUENCY of the all child would be tricky,
but we could have a separate config for the wait time and put the burden on the user to set
the config appropriately. I think we'd need a new PENDING_DROP index status that would keep
maintenance going and some kind of cron job that does the actual removal of the index metadata.
Or maybe we could let the index metadata be collected at compaction time and just start filtering
out the index from the PTable after the configurable time expires? The implementation would
require some thought.

> Handle drop of shared index when UPDATE_CACHE_FREQUENCY is set
> --------------------------------------------------------------
>
>                 Key: PHOENIX-4023
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4023
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>
> When UPDATE_CACHE_FREQUENCY is set, a client will continue to use a shared index (i.e.
local index or view index). This is not good because once it's dropped, it will stop being
maintained which will lead to incorrect query results.
> Some potential options:
> # Ignore UPDATE_CACHE_FREQUENCY if a table has a shared index. Not great because it defeats
the purpose of the feature.
> # Delay the index actually being dropped (or at least the stopping of the maintenance)
until the cache frequency passes. Makes some assumptions about the UPDATE_CACHE_FREQUENCY
as it could vary on a connection by connection basis.
> #. Do nothing and let the index continue to be used (figuring it's usage will stop when
the UPDATE_CACHE_FREQUENCY occurs and that's the cost of using this feature).
> Option #2 seems the most viable. Perhaps a separate config for how long to continue to
do index maintenance after an index is dropped.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message