public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nadav Shatz <[email protected]>
To: [email protected]
Subject: Re: Proposal: Recent mutated table tracking in memory
Date: Mon, 26 Jan 2026 13:02:40 +0200
Message-ID: <CACeKOO3j9oEXyNiTM+cnjbfr1eaKMEyKf8LM3HTBdVBdrBmVgw@mail.gmail.com> (raw)
In-Reply-To: <CACeKOO1NBExVWG0=wMKc+Kpk-RFXM2i1XTqzGdB9Z_pqg+5otg@mail.gmail.com>
References: <CACeKOO2hjPmstboJaa=rw8Erd7k5VhXyupU39bAosCPtUe1UBA@mail.gmail.com>
<CACeKOO1NBExVWG0=wMKc+Kpk-RFXM2i1XTqzGdB9Z_pqg+5otg@mail.gmail.com>
Doing another ping - sorry for that, it's been 20 days.
Would appreciate any feedback. thank you
On Wed, Jan 14, 2026 at 10:55 AM Nadav Shatz <[email protected]> wrote:
> 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
>
--
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]
Subject: Re: Proposal: Recent mutated table tracking in memory
In-Reply-To: <CACeKOO3j9oEXyNiTM+cnjbfr1eaKMEyKf8LM3HTBdVBdrBmVgw@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