Re: Proposal: Recent mutated table tracking in memory

Hi Tatsuo,

Thank you for all the great comments and questions! I took under
consideration all of them either adding support/tests or detailing the
limitations in the docs.

Let me know what you think of the latest patch attached here

On Wed, Feb 4, 2026 at 1:23 AM Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:

> From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
> Subject: Re: Proposal: Recent mutated table tracking in memory
> Date: Tue, 03 Feb 2026 16:43:53 +0900 (JST)
> Message-ID: <20260203(dot)164353(dot)362943818466117773(dot)ishii(at)postgresql(dot)org>
>
> > Hi Nadav,
> >
> > Thank you for updating the patch!
> >
> >> Thank you for the comments!
> >>
> >> I agree with all of them. Let me know what you think of the changes and
> new
> >> naming.
> >
> > I still think "memory_map" is too generic. Anything put on memory for
> > data mapping could be called "memory map". I recommend to change the
> > name to more feature specific one: What about replacing "memory_map"
> > with "track_table_mutation"? It's a little bit longer name but it
> > clearly represents the feature. Any better ideas are welcome.
> >
> > - 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)
> >
> > Also I feel memory_map_query_cache_size is confusing because there's
> > already "query cache" feature in pgpool. Can we change it something
> > like "query_parse_cache_size"?
> >
> > Review comments:
> >
> > (1) Why the regression test is 45? Shouldn't it be 42? (the last
> > feature test is 041.external_replication_delay).
> >
> > (2) You enhance the patch to deal with leader watch changing. That's
> > good. However, I don't see a test case for it in test.sh.
> >
> > (3) It seems the patch does not support TRUNCATE, MERGE, PREPARE and
> > WITH + updating. If so, it should be noted in the docs as a limitation
> > of the feature.
>
> (4) It seems the patch does not consider transactions. If an UPDATE is
> performed in a transaction and the transaction gets rollbacked, load
> balance is disabled despite that fact that the table modification did
> not happen.
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
>

--
Nadav Shatz
Tailor Brands | CTO