[ 
https://issues.apache.org/jira/browse/PHOENIX-7996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lokesh Khurana updated PHOENIX-7996:
------------------------------------
    Description: 
PHOENIX-7426 added server-side maintenance of immutable-table indexes behind
phoenix.server.side.immutable.indexes.enabled (default off). This hardens that
opt-in path and closes two correctness gaps. The default stays off; flipping it
on is a separate follow-up.

1. Partial-upsert read-back: IndexRegionObserver skips the read-back for 
immutable
   batches, so a partial upsert omitting an indexed/covered/index-WHERE column
   builds the index entry from the partial mutation alone — dropping a covered
   column, or writing a spurious null-keyed uncovered entry. Now forces a
   read-back only when an enabled mutation omits one of the index's on-disk
   columns; full-row upserts keep the fast path.

2. Uncovered global immutable indexes with a matching storage scheme were
   maintained by nobody: the serialize filter matched GLOBAL only. It now 
matches
   IndexUtil.isGlobalIndex (GLOBAL + UNCOVERED_GLOBAL).

ROW_TIMESTAMP carve-out: immutable tables with a ROW_TIMESTAMP column stay
client-maintained regardless of the flag (server-side re-stamping would break
ROW_TIMESTAMP range reads). The maintenance-side decision is centralized in
IndexUtil.isServerSideImmutableIndexMaintenanceEnabled(...) so client and server
never disagree.

  was:
PHOENIX-7426 added server-side maintenance of immutable global indexes, gated 
behind the client config phoenix.server.side.immutable.indexes.enabled (default 
false). When enabled, non-transactional, non-local immutable global indexes are 
maintained by IndexRegionObserver on the region servers instead of being 
generated on the client; because immutable rows have no prior state, the server 
skips the read-before-write that mutable-index maintenance requires.

This issue flips the default to true, so immutable-index maintenance is 
server-side out of the box.


>  Correctly maintain immutable global indexes on the server side for partial 
> upserts
> -----------------------------------------------------------------------------------
>
>                 Key: PHOENIX-7996
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-7996
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: Lokesh Khurana
>            Assignee: Lokesh Khurana
>            Priority: Major
>
> PHOENIX-7426 added server-side maintenance of immutable-table indexes behind
> phoenix.server.side.immutable.indexes.enabled (default off). This hardens that
> opt-in path and closes two correctness gaps. The default stays off; flipping 
> it
> on is a separate follow-up.
> 1. Partial-upsert read-back: IndexRegionObserver skips the read-back for 
> immutable
>    batches, so a partial upsert omitting an indexed/covered/index-WHERE column
>    builds the index entry from the partial mutation alone — dropping a covered
>    column, or writing a spurious null-keyed uncovered entry. Now forces a
>    read-back only when an enabled mutation omits one of the index's on-disk
>    columns; full-row upserts keep the fast path.
> 2. Uncovered global immutable indexes with a matching storage scheme were
>    maintained by nobody: the serialize filter matched GLOBAL only. It now 
> matches
>    IndexUtil.isGlobalIndex (GLOBAL + UNCOVERED_GLOBAL).
> ROW_TIMESTAMP carve-out: immutable tables with a ROW_TIMESTAMP column stay
> client-maintained regardless of the flag (server-side re-stamping would break
> ROW_TIMESTAMP range reads). The maintenance-side decision is centralized in
> IndexUtil.isServerSideImmutableIndexMaintenanceEnabled(...) so client and 
> server
> never disagree.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to