A kdb logfile typically has the form of (func;tabName;tabData), which can be as simple as f:{upsert[x;y]}. There isn’t anything special in terms of replaying the data into the kdb process, but more so to do with saving down the data.
Assuming you mean to save to another date, you could simply pull out a date from the data (after replay) and use it as a parameter for your save down logic.
If you mean at a higher level on partitioning the data differently across the entire database, data can be partitioned by any column of types date, month, year and int (1, 2), so depending on the requirements you could map values to a specific int based partition schema (3).
The Platform codebase is designed to write date partitioned HDB’s only.
The Intraday database - KX Platform exists to so that 24hrs of data does not need to be kept in memory, but it will again store to the HDB on a date partition only.
q)select from tab2
'./2021.01.02/tab2/b.
OS reports: No such file or directory
[0] select from tab2 ^
.Q.bv - would be one possible helpful extension which can in memory fill tables missing from partitions (using ` as argument to fill using first partition as a template)
q)\l HDB
q)select from tab1
date a
------------
2021.01.01 1
2021.01.01 2
2021.01.01 3
2021.01.02 4
2021.01.02 5
2021.01.02 6
q)select from tab2 //Table missing from latest partition is not found
'tab2
[0] select from tab2 ^
q).Q.bv` //Using ` first partition used as prototype and table is found
q)select from tab2
date b
------------
2021.01.01 1
2021.01.01 2
2021.01.01 3
(.Q.chk is unsuitable as it uses most recent partition as template to fills tables missing from partitions)
This is only one item that would be needed to implement what you asked.
Currently EOD is a single action for all tables, all code and processes involved would need updates to operate table by table. Meaning changes in RDB/IDB/HDB and others.