Skip to content

Conversation

@moticless
Copy link
Collaborator

@moticless moticless commented Jun 10, 2024

Reserve 2 bits out of hash-field expiration time (#define HFE_MAX_ABS_TIME_MSEC (EB_EXPIRE_TIME_MAX >> 2)) for possible future lightweight indexing/categorizing of fields. It can be achieved by hacking HFE as follows:

HPEXPIREAT key [ 2^47 + USER_INDEX ] FIELDS numfields field [field …]

Redis will also need to expose kind of HEXPIRESCAN and HEXPIRECOUNT for this idea. Yet to be better defined.

HFE_MAX_ABS_TIME_MSEC constraint must be enforced only at API level. Internally, the expiration time can be up to EB_EXPIRE_TIME_MAX for future readiness.

@moticless
Copy link
Collaborator Author

@tezc, rdb.c relies on EB_EXPIRE_TIME_MAX, and I think that is fine. Please consider what I wrote at the end of description of this PR.

@tezc
Copy link
Collaborator

tezc commented Jun 10, 2024

Yes, I saw it later.

@moticless moticless merged commit f01fdc3 into redis:unstable Jun 10, 2024
@moticless moticless deleted the reserve-2bits-future-use branch June 10, 2024 13:57
funny-dog pushed a commit to funny-dog/redis that referenced this pull request Sep 17, 2025
…is#13331)

Reserve 2 bits out of hash-field expiration time (`EB_EXPIRE_TIME_MAX`)
for possible future lightweight indexing/categorizing of fields. It can
be achieved by hacking HFE as follows:
```
HPEXPIREAT key [ 2^47 + USER_INDEX ] FIELDS numfields field [field …]
```

Redis will also need to expose kind of `HEXPIRESCAN` and `HEXPIRECOUNT`
for this idea. Yet to be better defined.

`HFE_MAX_ABS_TIME_MSEC` constraint must be enforced only at API level.
Internally, the expiration time can be up to `EB_EXPIRE_TIME_MAX` for
future readiness.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants