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 1sfx80-00Ddy5-3n for pgsql-general@arkaria.postgresql.org; Mon, 19 Aug 2024 07:48:36 +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 1sfx7x-00Gs9L-Cc for pgsql-general@arkaria.postgresql.org; Mon, 19 Aug 2024 07:48:34 +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 1sfx7x-00Gs9A-1n for pgsql-general@lists.postgresql.org; Mon, 19 Aug 2024 07:48:33 +0000 Received: from mail-vs1-xe30.google.com ([2607:f8b0:4864:20::e30]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sfx7u-000P8w-J7 for pgsql-general@lists.postgresql.org; Mon, 19 Aug 2024 07:48:33 +0000 Received: by mail-vs1-xe30.google.com with SMTP id ada2fe7eead31-4928da539c3so1178355137.1 for ; Mon, 19 Aug 2024 00:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724053709; x=1724658509; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=5cUGtQzcTF93Fsj+BVGeCtOt9HW7zWoTY2uzpNEkpRo=; b=Z9tB3xCG1FaLglEq+/Nc40N86CJZhBO04qTCEQl5PRD3Pk8Y1MYtuuKQyu58Vg6JuZ 95y/dkCLYrdTMaWk8veG3UqykGeF6KuaMcF9i3x61k8rdaFHpau4+i8Xp1YqaY5p91nt vvkthI0rgo0caJn/oTaEAv6BG8QWcJuR7kxDyYJ83/c3gzvN5hWrABwkgQqx0dK0Zj/Z XWbgaaRr/C4E8/TltJij1F2k9pLJs+zk4wCPvs/mopfO2S0sNDdRYediA1kRs4iwgBcn BmG4baPufLEa6tkZAEoiRDTBSxPnlBARa3HkrzQICitmCCdmtp1Fj3lGhIx83MXoZTE4 Ny1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724053709; x=1724658509; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5cUGtQzcTF93Fsj+BVGeCtOt9HW7zWoTY2uzpNEkpRo=; b=c7gKOTgerqYAxSJRBEO3vZtyZ4Hh900eB6rN3Iuz0VgGwM1v7c2uZPCPxplcQB9o9p oI6/0wfcadtESQNS6wAR9awq3URcnEwy3eIrbZMq6SLDnzPRu8tWFGUPCoQxp0S33mA6 wxb+hFj574xNhhxeXQERc0y8fdTK04Y25MsG0yTxxxDd4yB+fiePxdgl7pNZ9XGXCAGK OX8YRMMklaXsFT7DC2DcoSqrNFkYKJjiI8DLILoUaKSk6urY2QwnIufFpmSO4xn3uz7T 5CKAJT9APjK5uIrTxm2BxfxrJZ8qdHFJFbUgxK7utl4b6nSrmAOPDzOUdNRdb9YvMszg RTdw== X-Gm-Message-State: AOJu0YwPlw5j6IkF47bYKZFdsrrHxnXLCTjadWPf3mTyXwXg7ewzftIu c4yZImG7WgrFgzHNMLtI34UHt183BCr5Fet6NgxOP2noSXDcIGo23lsmODZifPENa+I+DSwinOR HLBiNpvQTEE56a/4Pi6S/+5sv/i+jFA== X-Google-Smtp-Source: AGHT+IHOMw6lIH9veuJL3YewCRUlasWk6E4b10SdtiBwR9MYwTfsdEc+eIMlGQauXTmOrXgbZRbYn2XslD3xYDzbKzw= X-Received: by 2002:a05:6102:6cd:b0:48f:95cd:e601 with SMTP id ada2fe7eead31-497799b40fdmr8258301137.25.1724053709045; Mon, 19 Aug 2024 00:48:29 -0700 (PDT) MIME-Version: 1.0 From: sud Date: Mon, 19 Aug 2024 13:18:18 +0530 Message-ID: Subject: Insert query performance To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000e6c8a50620048812" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e6c8a50620048812 Content-Type: text/plain; charset="UTF-8" Hello All, In a version 15.4 postgres database, Is it possible that , if we have two big range partition tables with foreign key relationships between them, insert into the child table can cause slowness if we don't have foreign key index present in the child table? Basically it need to make sure the new row already added to parent partition table or not. And if there is any possible way(example query tracing etc) to get the underlying system queries which gets triggered as part of the main insert query? For example in above scenario, postgres must be executing some query to check if the incoming row to the child table already exists in the parent table or not? Regards Sud --000000000000e6c8a50620048812 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello All,=C2=A0

In a ve= rsion 15.4 postgres database, Is it po= ssible that , if we have two big range partition tables with foreign key re= lationships between them, insert into the child table can cause slowness if= we don't have foreign key index present in the child table? Basically = it need to make sure the new row already added to parent partition table or= not.=C2=A0

=C2=A0
And if there is any possible way(examp= le query tracing etc) to get the underlying system queries which gets trigg= ered as part of the main insert query? For example in above scenario, postg= res must be executing some query to check if the incoming=C2=A0 row to the = child table already exists in the parent table or not?=C2=A0


Regards

Sud

--000000000000e6c8a50620048812--