> Then I suppose the behavior you describe should be enabled/disabled by flag.
Yes. This feature will change Ignite behavior. It will be enabled by the flag. > How do you plan to implement this? Sent tx state to the node performing table/index scan and combine both Btree and tx data there. > Which limitations do you see? 1. Transaction data stored in heap - huge transactions will lead to the GC pressure. 2. Network overhead - Ignite sent tx changes when executing SQL queries fragments. > On 15 Jul 2024, at 15:31, Maksim Timonin <timoninma...@apache.org> wrote: > > Hi Nikolay! > > I have a few questions: > >> Ignite primary use-cases are around OLTP workload which means we deal with >> small and fast transactions that change coupld of entries > > I know at least one popular use-case of our clients. Some clients have pretty > complex logic of clearing data. They use Scan and Index queries to iterate > over caches with their own logic. Also I believe there are users that don't > need the guarantees you describe. Then I suppose the behavior you describe > should be enabled/disabled by flag. > >> This will allow to SQL engine to mixup transaction state and table(index) >> data to achieve correct results > > How do you plan to implement this? Which limitations do you see? >
