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.94.2) (envelope-from ) id 1vBDKH-00CrAS-3R for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Oct 2025 14:27:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1vBDKG-009bOX-3O for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Oct 2025 14:26:59 +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.94.2) (envelope-from ) id 1vBDKF-009bOP-QI for pgsql-hackers@lists.postgresql.org; Tue, 21 Oct 2025 14:26:58 +0000 Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vBDKC-003RX6-1I for pgsql-hackers@postgresql.org; Tue, 21 Oct 2025 14:26:58 +0000 Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-33e0008d3b3so731036a91.3 for ; Tue, 21 Oct 2025 07:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761056814; x=1761661614; darn=postgresql.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/QTXLvbZZVAjvJjE6aTnGpDWjEvL0l52ISdWbhQzFAU=; b=XnC7HZWphcVJblLFECPNYNyNzXH3W+KdKBvopAz4LuU41uTtd+/Z5XAR1pmSI5kiv7 FkW3Nx01fOtJZ1OU7tVFWBmQItw5KqeeKacNzpT1Vt/7NFP2RpcheQp1qfCwaVA9MsR8 Fhma24GkWZRrp0lOQT2R7f72A15E28Qwr4ZTK4lxOxsVjjaHutVpyBVAdI8BcVdmY/s+ HbFDwQLGkYI+PJneBrYyKGNHbBQGXgBnMhdx1VNeaS32SF3zQBKaorjDFyG5OOHhZVlt gLqxXKe9QNBs5W75ICbiZdq2LYGGj2UBqPof/tiT+X52TWC7bsr/iQf2YA1OoSZREB2f RpWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761056814; x=1761661614; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=/QTXLvbZZVAjvJjE6aTnGpDWjEvL0l52ISdWbhQzFAU=; b=AWTnW9QzAwEkgkXAV1AXILPTgAw+gTEUC2UO67gMF57KQ4dcEJyaz7vJazyASuCXUV /u+ozeqHS2gD/yFSdtFdNvML45M/0C/vhYMSqpRCwNDzpdPK2dg91QsLHJolVVp2zfry GRcd7EkrItPyhXF6FemskH2HXPLmpN2LiDmM8+tu6vWrZ7ud0p5IVnz/xtRkVwlmc+sm 6tH4W4Un+LtpcH4x7etYjkidmHFRxRI9Zgz4/5OoxtDPTb8yAX0Ke1pzAfkfUP53gmH1 9VpoW7HbExzDXV1JIUdUZ0l1KIYVf+ckPuT7VYjuO5fsY1amph523UCbl9hAPNr9hd7F 1THA== X-Forwarded-Encrypted: i=1; AJvYcCXJcSgwSJw4eoegN27YmdpLqS/QYhM6JqiJNxMoD3t4Fw1PgL6crkSfcztp+cHD3Jzt2UKI0pK0x5BVR6wh@postgresql.org X-Gm-Message-State: AOJu0YxA6uWUj8kfLxQhB2M73Ot1B8ShNZF2SY0KLeeP19RmMlb83/mB eXq+/TxKLYqKdm/buFwx4AwDIP8DvHBhBJTkINgAXyqQQBK8sTJQeKrl X-Gm-Gg: ASbGncteW0PYJ6BX32pKNJGNhQv7LxBztIiEkLSvjBQvHTQUxLjwu2Eymvzz/S0r5qo i5q2FobH9GWpe2ADL++/ScPbXV7T67IMbdkH5RXbLDXjff9oQcVfPMinI0FSbq473Snd4PWDCwN bTSUtMebd7ywbBFITprnHr4eWeGbFCqgirLXIsXs+oQwNz0k58SJR32n0KAc6IxfDhNsz5xB2kZ 70LBdQkH+2pPViPqpLr3iIvf/VU+EPrU2uVJKw6w+d5QM5AYSh8eH8Va8WjdKXD/DGJPX+7OwU+ oE74X+hzypTNJ299/n5DlENBf/uBmW93OgrnQGHXVL6aH5/wrDPR9p/ROclaowpiwT84rwk+/T/ 2DfO4+uf36ZR/Y/C9jfcqNxPvkYrcosi7oI/+vM4NhT7wM7lwfCXQHxZBmji+WswQKXwq8SWpQ9 JMY1th+ls+/KKqnIHzBdCp2mJiHY85tYgl/Q== X-Google-Smtp-Source: AGHT+IHB0OFR/bcp/HeIIQyQOjamqfPrn8w8f/qMD/OLFf/FGC+CDG1wk1gLchxYsn7y9qdJ+yPd5w== X-Received: by 2002:a17:90b:1d44:b0:32b:ca6f:1245 with SMTP id 98e67ed59e1d1-33bcf85b2ebmr20278499a91.5.1761056814438; Tue, 21 Oct 2025 07:26:54 -0700 (PDT) Received: from localhost ([2804:14d:328a:a59c:e4b1:4897:5aa2:cffe]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-33d5de11601sm11140993a91.9.2025.10.21.07.26.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Oct 2025 07:26:54 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 21 Oct 2025 11:26:50 -0300 Message-Id: Cc: "Matheus Alcantara" , Subject: Re: postgres_fdw: Use COPY to speed up batch inserts From: "Matheus Alcantara" To: "Jakub Wartak" , "Tomas Vondra" X-Mailer: aerc 0.21.0 References: In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thanks for testing and for the comments! On Fri Oct 17, 2025 at 6:28 AM -03, Jakub Wartak wrote: > On Thu, Oct 16, 2025 at 10:42=E2=80=AFPM Tomas Vondra w= rote: >> Thanks for the patch. Please add it to the next committfest (PG19-3) at > > Hi Matheus! same here - thanks for the patch! > >> > The attached patch uses the COPY command whenever we have a *numSlots = > >> > 1 but the tests show that maybe we should have a GUC to enable this? >> > >> >> I can imagine having a GUC for testing, but it's not strictly necessary. > > Just note, I've played maybe like 20mins with this patch and it works, > however if we would like to have yet another GUCs then we would need > to enable two of those? (enable batch_size and this hypothetical > `batch_use_copy`?) > I was thinking in a GUC to enable to use the COPY command if the number of rows being ingested during the batch insert is greater than the value configured on this GUC, something like, batch_size_for_copy. But for now I'm starting to think that perhaps we may use the COPY if the batch_size is configured to a number > 1(or make this configurable?). With this it would make more easier to show on EXPLAIN that we will send a COPY command to the remote server instead of INSERT. The currently patch relies on the number of rows being sent to the foreign server to enable the COPY usage or not, and IUUC we don't have this information during EXPLAIN. I wrote more about this on my previous reply [1]. > Some other stuff I've tried to cover: >... > 4. I've found that big rows don't play with COPY feature without > memory limitation, so probably some special handling should be done > here, it's nonsense , but: > > postgres@postgres:1236 : 15836 # INSERT INTO local_t1 (id, t) > SELECT s, repeat(md5(s::text), 10000000) from generate_series(100, > 103) s; > 2025-10-17 11:17:08.742 CEST [15836] LOG: statement: INSERT INTO > local_t1 (id, t) SELECT s, repeat(md5(s::text), 10000000) from > generate_series(100, 103) s; > 2025-10-17 11:17:08.743 CEST [15838] LOG: statement: START > TRANSACTION ISOLATION LEVEL REPEATABLE READ > 2025-10-17 11:17:38.302 CEST [15838] LOG: statement: COPY > public.t1(id, t, counter) FROM STDIN (FORMAT TEXT, DELIMITER ',') > ERROR: string buffer exceeds maximum allowed length (1073741823 byte= s) > DETAIL: Cannot enlarge string buffer containing 960000028 bytes > by 320000000 more bytes. > 2025-10-17 11:17:40.213 CEST [15836] ERROR: string buffer exceeds > maximum allowed length (1073741823 bytes) > 2025-10-17 11:17:40.213 CEST [15836] DETAIL: Cannot enlarge > string buffer containing 960000028 bytes by 320000000 more bytes. > 2025-10-17 11:17:40.213 CEST [15836] STATEMENT: INSERT INTO > local_t1 (id, t) SELECT s, repeat(md5(s::text), 10000000) from > generate_series(100, 103) s; > > but then it never wants to finish that backend (constant loop[ in > PQCleanup() or somewhere close to that), server behaves unstable. > Without batch_size set the very same INSERT behaves OK. > On the last version that I sent on [1] I introduce a buffer size limit, and testing this INSERT statement with the latest version seems to fix this issue. Could you please check this too? [1] https://www.postgresql.org/message-id/CAFY6G8ePwjT8GiJX1AK5FDMhfq-sOnny= 6optgTPg98HQw7oJ0g%40mail.gmail.com -- Matheus Alcantara