| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | nadav(at)tailorbrands(dot)com |
| Cc: | pgpool-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Proposal: Recent mutated table tracking in memory |
| Date: | 2026-02-03 23:23:43 |
| Message-ID: | 20260204.082343.1732190257543250666.ishii@postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgpool-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nadav Shatz | 2026-02-06 11:29:10 | Re: Proposal: Recent mutated table tracking in memory |
| Previous Message | Tatsuo Ishii | 2026-02-03 07:43:53 | Re: Proposal: Recent mutated table tracking in memory |