Hi Julian, Yes, marking an index as UNUSABLE simply means it won't be considered at query time. It will still be maintained. If you DISABLE it, then you won't be hit with the maintenance cost, but we don't have a mechanism to partially rebuild it. See PHOENIX-2890 and the WIP patch. In theory, if you get the cell time stamp of the INDEX_STATE cell (i.e. when it was set to DISABLE), don't attempt to delete existing rows for the index, and then use this time stamp as the min time stamp of the UPSERT SELECT that rebuilds the index, it should just work (sens edge cases of any out of order data row updates). Thanks, James
On Mon, Aug 15, 2016 at 4:46 PM, Julian Jaffe <[email protected]> wrote: > Hi all, > > Does Phoenix use the same execution path for updating indices mark as > UNUSABLE as it does for USABLE indices (that is, will indices marked as > UNUSABLE require an additional write for every upsert, just as USABLE > indices will)? If maintaining an unsuable index still requires an extra > write, is there a way instead to disable an index without forcing a full > rebuild if it's reenabled? We're replacing a few indices and are trying to > ensure we can roll back quickly if something goes wrong instead of having > to wait to rebuild a large index. > > Thanks, > Julian Jaffe >
