Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vnPkV-006mKx-2b for pgpool-hackers@arkaria.postgresql.org; Tue, 03 Feb 2026 23:24:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vnPkU-007yln-3A for pgpool-hackers@arkaria.postgresql.org; Tue, 03 Feb 2026 23:23:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vnPkU-007yl9-2a for pgpool-hackers@lists.postgresql.org; Tue, 03 Feb 2026 23:23:58 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vnPkR-00000000voo-3gTT for pgpool-hackers@lists.postgresql.org; Tue, 03 Feb 2026 23:23:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Content-Transfer-Encoding:Content-Type: Mime-Version:References:In-Reply-To:From:Subject:Cc:To:Message-Id:Date:Sender :Reply-To:Content-ID:Content-Description; bh=3Hk7JaaGYXWke4uK7RmzapN1ZiBT+gf/4pfgSutVk8U=; b=gk+8qjGsRYk7vdt2XICkAyayze 4I9oznwYaw2lENBKxRMeyW09YOR7VAyv0h1sFI/9K6/zYcZ11o+KC0z+BCzDTjV14VJUPuR4RSOO7 sWki147/fE9yjLYv0V6Rd1viwNaJFnirFBKjLTretAbuAPDJZBBSyEMCeEFYf6BJgBS2My+zcIltd r1xzwpoMBttZ3nvGoVthV+8wHfjuqiT16LgX42TkXkitZ5GhNPALWZBxZLJHFAjFrDg3cK+7bfzAm QLWxvMMGKForpk4/A+/FC1k84FzzaIF6Bly6BM2VIqLhAs0UJ7BRv68la90tBHrPBYdmglK1Nm3pv satd+hoQ==; Received: from [2409:11:4120:300:65e8:5beb:3461:390e] (helo=localhost) by meldrar.postgresql.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vnPkP-002CI9-17; Tue, 03 Feb 2026 23:23:55 +0000 Date: Wed, 04 Feb 2026 08:23:43 +0900 (JST) Message-Id: <20260204.082343.1732190257543250666.ishii@postgresql.org> To: nadav@tailorbrands.com Cc: pgpool-hackers@lists.postgresql.org Subject: Re: Proposal: Recent mutated table tracking in memory From: Tatsuo Ishii In-Reply-To: <20260203.164353.362943818466117773.ishii@postgresql.org> References: <20260130.170950.551399957723794225.ishii@postgresql.org> <20260203.164353.362943818466117773.ishii@postgresql.org> X-Mailer: Mew version 6.8 on Emacs 29.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2409:11:4120:300:65e8:5beb:3461:390e (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk From: Tatsuo Ishii Subject: Re: Proposal: Recent mutated table tracking in memory Date: Tue, 03 Feb 2026 16:43:53 +0900 (JST) Message-ID: <20260203.164353.362943818466117773.ishii@postgresql.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