You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "James Taylor (JIRA)" <ji...@apache.org> on 2018/03/20 21:45:04 UTC
[jira] [Updated] (PHOENIX-4023) Handle drop of shared index when
UPDATE_CACHE_FREQUENCY is set
[ https://issues.apache.org/jira/browse/PHOENIX-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Taylor updated PHOENIX-4023:
----------------------------------
Description:
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.
was:
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.
> 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
> Priority: Major
>
> 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
(v7.6.3#76005)