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 1sqIGo-008VaK-8K for pgsql-general@arkaria.postgresql.org; Mon, 16 Sep 2024 20:24:27 +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 1sqIGl-00HMOu-Vw for pgsql-general@arkaria.postgresql.org; Mon, 16 Sep 2024 20:24:23 +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 1sqIGl-00HMOl-KM for pgsql-general@lists.postgresql.org; Mon, 16 Sep 2024 20:24:23 +0000 Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sqIGi-001XKO-7U for pgsql-general@lists.postgresql.org; Mon, 16 Sep 2024 20:24:23 +0000 Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-5356ab89665so5407855e87.1 for ; Mon, 16 Sep 2024 13:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726518259; x=1727123059; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=UfAMLT6QhQluzo4PYk+605E/m7X0fLVWgIcQ34jEsSc=; b=GGkltqAoWGM5MlQe6BiwDUPwz1g1Cv9R4zD3+yr96u9j6bOHuNau27pHWZKA6cRi7W K3OpBwcbdcsXlDApg0DeDpEIzbZfVOfIi3NCj1Qf3fL3dTxRAvgbQYK2lfVr5Mzd1Unm n/dZQLI4EPJTLMGYKNgrPHnfkpde21ZvSsWmPM+sexsUWQgxaPEN+XOHhSJhoIhJ5Xo6 hoSUvYEaTExXoWY19Ua08hE+z+eKaaVfCXI6rCGiZAwHLVtj3gZQJ/ycEpAuElALrG2x vEUUlRxyZeh1jidTkiZkd/JvCg9AV7v5aaIJm36wopuFrKAqMVj82VEr1jskhs6WRfD2 Epww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726518259; x=1727123059; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UfAMLT6QhQluzo4PYk+605E/m7X0fLVWgIcQ34jEsSc=; b=RlE3ZpYSIaVTyhdlC1Ps6w9h9DN3z+v2jgbI8ENeHn0UJWoTFcHTlwdPXzZ1QFAKY3 wa21uoPNnHWjzqno9OV7u6ngyjpVWaLm9hPyFYFe99gizrgXZ1OXHPkPzifjHx5J3syh 6ol1tGqKIZcRNUCAWEKxHNkE3apNLQQ6E39JHSifEpxNi4qyyT/mKfewSSUQYBf57cpH 6LQOGCtZ0Xfnh0K3Q4XrpZWD/vk8jyEJSBewYR8rYJHmmKhylqDcBuPuOc3NB9ira1P7 d7UisgTL2NWob/76B54xySK6Yxtczn1RZOPNOBEVVJN9aAszcMMI3CxsJ4pxAkXdERoa 2AZg== X-Gm-Message-State: AOJu0YyfUaEZTLn0uBXrjEMsDTmYp2OdDMOBDCYeiAmZs1ANOH1RSC3l g7XLWZnR2BWuxOk1/OaA7JoY9eJ5zrycWaaqAq8Qofrv0e3WcwdNHJHR+CKCT/NMXKn2e2euBOZ C8FLVNBuY57tNW5dkXTaPicDQVWRsUA== X-Google-Smtp-Source: AGHT+IH8hoxXVhTBJT8/CnFMpRvXp9xf7i1DBu3XZ8JryLCVIk9LMNuTC0RVeUQskyxjaovTw2/ghxuu2HWcA/eMutw= X-Received: by 2002:ac2:5687:0:b0:536:7d7d:c636 with SMTP id 2adb3069b0e04-5367d7dc706mr8054090e87.32.1726518258843; Mon, 16 Sep 2024 13:24:18 -0700 (PDT) MIME-Version: 1.0 From: veem v Date: Tue, 17 Sep 2024 01:54:07 +0530 Message-ID: Subject: IO related waits To: pgsql-general Content-Type: multipart/alternative; boundary="0000000000008449970622425b02" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000008449970622425b02 Content-Type: text/plain; charset="UTF-8" Hi, One of our application using RDS postgres. In one of our streaming applications(using flink) which processes 100's of millions of transactions each day, we are using row by row transaction processing for inserting data into the postgres database and commit is performed for each row. We are seeing heavy IO:XactSynch wait events during the data load and also high overall response time. Architecture team is suggesting to enable asynch io if possible, so that the streaming client will not wait for the commit confirmation from the database. So I want to understand , how asynch io can be enabled and if any downsides of doing this? Regards Veem --0000000000008449970622425b02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0
One of= our application using RDS postgres. In one of our streaming applications(u= sing flink) which processes 100's of millions of transactions each day,= we are using row by row transaction processing for inserting data into the= postgres database and commit is performed for each row. We are seeing heav= y IO:XactSynch wait events during the data load and also high overall respo= nse time.=C2=A0

Architec= ture team is suggesting to enable asynch io if possible, so that the stream= ing client will not wait for the commit confirmation from the database. So = I want to understand , how asynch io can be enabled and if any downsides of= doing this?=C2=A0

Regar= ds
Veem
--0000000000008449970622425b02--