phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas D'Silva (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4023) Handle drop of shared index when UPDATE_CACHE_FREQUENCY is set
Date Tue, 20 Mar 2018 23:32:00 GMT

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

Thomas D'Silva commented on PHOENIX-4023:
-----------------------------------------

[~karanmehta93] this would be a good JIRA for you to work on.
FYI [~sukunaidu@gmail.com]

> 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)

Mime
View raw message