public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nadav Shatz <[email protected]>
To: Tatsuo Ishii <[email protected]>
Cc: [email protected]
Subject: Re: Proposal: Recent mutated table tracking in memory
Date: Wed, 28 Jan 2026 07:37:07 +0200
Message-ID: <CACeKOO3_ZPkwfBv1ng=upHsDSMoWSLYBfnqYD1wkoV83rHTsAw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CACeKOO2hjPmstboJaa=rw8Erd7k5VhXyupU39bAosCPtUe1UBA@mail.gmail.com>
<CACeKOO1NBExVWG0=wMKc+Kpk-RFXM2i1XTqzGdB9Z_pqg+5otg@mail.gmail.com>
<[email protected]>
Thank you Tatsuo!
Nadav Shatz
Tailor Brands | CTO
On Wed, Jan 28, 2026 at 7:08 AM Tatsuo Ishii <[email protected]> wrote:
> Hi Nadav,
>
> Sorry for the late reply. I just your email now. Will check and reply
> back soon.
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
>
> > Hi all,
> >
> > Any comments or concerns? can we merge it if not?
> >
> > On Tue, Jan 6, 2026 at 1:25 PM Nadav Shatz <[email protected]>
> wrote:
> >
> >> Hello,
> >>
> >> As initially proposed under "Proposal: recent access based routing for
> >> primary-replica setups" and then broken into separate tasks - i am
> adding
> >> here a patch to implement tracking of latest mutated table, and then
> using
> >> the replication lag as a base - deciding where to point queries when
> query
> >> load balancing and parsing is enabled.
> >>
> >> More details as in the patch:
> >> Feature: add in-memory table tracking to prevent stale reads from
> replicas
> >>
> >> Implement "memory map" feature that tracks recently-written database
> >> tables in shared memory to prevent stale reads during replication lag.
> >> When a write (INSERT/UPDATE/DELETE) occurs on a table, that table is
> >> marked as "dirty" for a configurable TTL period. Any SELECT on a dirty
> >> table within the TTL window is routed to primary instead of replica.
> >>
> >> Key features:
> >> - Shared memory hash table for tracking table mutations with TTL
> >> - Query parse cache with LRU eviction for performance
> >> - Cold start protection (routes all queries to primary initially)
> >> - Automatic TTL calculation: replication_delay × configurable factor
> >> - Per-table staleness tracking with microsecond precision
> >>
> >> New configuration parameters:
> >> - memory_map_enabled: Enable/disable the feature (default: off)
> >> - memory_map_ttl_factor: TTL multiplier for replication delay (default:
> >> 5.0)
> >> - memory_map_cold_start_duration: Cold start period in ms (default:
> 2000)
> >> - memory_map_table_buckets: Hash buckets for table map (default: 1024)
> >> - memory_map_table_size: Max tracked tables (default: 2048)
> >> - memory_map_query_buckets: Hash buckets for query cache (default: 2048)
> >> - memory_map_query_cache_size: Max cached queries (default: 10000)
> >>
> >> Patch applies properly and tests pass.
> >>
> >> Open to all feedback - thank you!
> >>
> >> --
> >> Nadav Shatz
> >> Tailor Brands | CTO
> >>
> >
> >
> > --
> > Nadav Shatz
> > Tailor Brands | CTO
>
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Proposal: Recent mutated table tracking in memory
In-Reply-To: <CACeKOO3_ZPkwfBv1ng=upHsDSMoWSLYBfnqYD1wkoV83rHTsAw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox