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 1v1qT8-00DDaB-42 for pgsql-general@arkaria.postgresql.org; Thu, 25 Sep 2025 18:13:26 +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 1v1qT6-004TcV-PV for pgsql-general@arkaria.postgresql.org; Thu, 25 Sep 2025 18:13:24 +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 1v1kHK-002BY1-RP for pgsql-general@lists.postgresql.org; Thu, 25 Sep 2025 11:36:50 +0000 Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v1kHI-0000mq-0L for pgsql-general@postgresql.org; Thu, 25 Sep 2025 11:36:50 +0000 Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-36c5527a46bso8477261fa.0 for ; Thu, 25 Sep 2025 04:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758800207; x=1759405007; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=dSQSQJV12MrP+9aE9KdOxuwrBR1TLrC5qd3h/RYtWgs=; b=g2YWZ9glE1eEzKXjxw3wofXYsRVtiGwbO21t1oDyFVe97VHPL/lIAKwBTbbybm92ds o0FrcxVDZoA+nEY1NUQ3Xabn7VQ6MzHgH50hLVjlJl2iuVqtWYCRmj/erNUYc3NaQDTn edIAhKdzLspEDDjqU5CImf18OVivN63iKeAxthTCNbm3RF+hUXU7487ncPl2q63UV/5a rEdt1Vvcm4CWj3GrPOhYZ133vO+P+05Qb5TIgs8EejEPhZXG/JRAcj9oNRQWAhexNFSX naBBtw0tTqo0mifhQth9tr1bqZ5ZVgH3h4WDBdjHh0wd5qlXYQVK+FpjlohoyYrxKzBk artQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758800207; x=1759405007; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dSQSQJV12MrP+9aE9KdOxuwrBR1TLrC5qd3h/RYtWgs=; b=REojIpce1O/70NA0aPP2whtW56Q5LexfN9e32f1l/0UvohUo8/pa0dT9flQW+JC5pf /ue4IiNVlcZ+A4tBl3RZRbtZz2F69munodrhTTWies1p6YSRWXVu2tUKNPyBzqsK5EzB t+PF9KmInv5o9jQrwCbsgPu2JHDav8/ktSAIz3Oe7L5tKFb18CUGny1tSdOOKIgSI0Ha ck6PuYe7qtM+ThVFwC+ckcXvqV6qB2bvTsWDeIvMoc0zauNilPDRt4iso7huCCitZAJw HFmA4NrsuX7MrlfSt8r+yWxPPmSO5Dp9r6RjWa8uboXnDw5RBHQMDB/Jmj78qn90jRNi PuYg== X-Gm-Message-State: AOJu0YxM44NbPt+kGgGZdQlqG/A+vAWJWAuimOjQgZuSwOxIeQ3BqndL jy+24xgxSc6aT5Csa/ZhYJAPTO7c7sMTHz3xfbPoCS6UMoI0wh+nm1tfo7Nvqf+BCgo6qZ0cqCl lJK/EKBIXK81VMeHK8iiPU1E5FMA8LTHUnaH+SIo= X-Gm-Gg: ASbGncuhtbOAdnRA88Oii/infU1YeQ+m2+AXsqDpDwe8dk1HfKpLWn3qJ9OcQ9wgLds y0eC6+ah4OS3VcxThsG93mo7jNZjKSwtyxci8sA105p4b/RTg9buTAMP7Q0bahV/lBP18II02Zx X+8PeeAqvIN3XNEJCAoPCtm7hsT7z5F25DDsgYdawKotqb+cNfULzjjttdoUvpse8YdhB7oYlLr 5kVqRX6jkNV5UJvH6hNbTk77wXcAdcGIsEEAmf9/z1DV0bU X-Google-Smtp-Source: AGHT+IGgyTnF1Ib0MbWb+PmV/tRS8T7HDIawREkJG9rd8TlhrKQ1jbvs6elzQhObGXZvKVlcX7+eYrdmlv5ZzyItKCM= X-Received: by 2002:a2e:a54a:0:b0:36f:77e6:d25a with SMTP id 38308e7fff4ca-36f814a83cdmr7960681fa.43.1758800206553; Thu, 25 Sep 2025 04:36:46 -0700 (PDT) MIME-Version: 1.0 From: Ashish Mukherjee Date: Thu, 25 Sep 2025 17:06:33 +0530 X-Gm-Features: AS18NWAkfeH45PVI58qG4HRTWS8-1ZLNNFrLg0l_fFH2ecXh14DMx88IFYzJavQ Message-ID: Subject: Enquiry about Percona TDE performance issues To: pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary="0000000000008ae815063f9e95f5" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000008ae815063f9e95f5 Content-Type: text/plain; charset="UTF-8" Hello, I recently upgraded from pgsql 12 to pgsql 17. It's a Percona TDE enabled database. However, after the upgrade the query planning time has shot up by 10x when I check explain analyze output. The difference in planning time is visible here. The first case is pgsql 17 with TDE. The second case pgsql 12 with TDE. s14=> explain analyze select invoicenum from ltlinvoice where pseq=1400000224216382; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------ Index Scan using ltlinvoice_pseq on ltlinvoice (cost=0.43..10.10 rows=9 width=12) (actual time=0.040..0.040 rows=0 loops=1) Index Cond: (pseq = '1400000224216382'::bigint) Planning Time: 158.199 ms Execution Time: 0.051 ms s14=> explain analyze select invoicenum from ltlinvoice where pseq=1400000224216382; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------ Index Scan using ltlinvoice_pseq on ltlinvoice (cost=0.43..10.10 rows=9 width=12) (actual time=0.023..0.023 rows=0 loops=1) Index Cond: (pseq = '1400000224216382'::bigint) Planning Time: 0.195 ms Execution Time: 0.046 ms Any pointers about this would be helpful. Regards, Ashish --0000000000008ae815063f9e95f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I recently upgraded from pgsql 1= 2 to pgsql 17. It's a Percona TDE enabled database. However, after the = upgrade the query planning time has shot up by 10x when I check explain ana= lyze output.=C2=A0

The difference in planning time= is visible here. The first case is pgsql 17 with TDE. The second case pgsq= l 12 with TDE.

s14=3D> explain analyze select i= nvoicenum from ltlinvoice where pseq=3D1400000224216382;
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 QUERY PLAN
-------------------= ---------------------------------------------------------------------------= --------------------------------
=C2=A0Index Scan using ltlinvoice_pseq = on ltlinvoice =C2=A0(cost=3D0.43..10.10 rows=3D9 width=3D12) (actual time= =3D0.040..0.040 rows=3D0 loops=3D1)
=C2=A0 =C2=A0Index Cond: (pseq =3D &= #39;1400000224216382'::bigint)
=C2=A0Planning Time: 158.199 ms
= =C2=A0Execution Time: 0.051 ms

s14=3D> explain analyze select inv= oicenum from ltlinvoice where pseq=3D1400000224216382;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 QUERY PLAN
----------------------= ---------------------------------------------------------------------------= -----------------------------
=C2=A0Index Scan using ltlinvoice_pseq on = ltlinvoice =C2=A0(cost=3D0.43..10.10 rows=3D9 width=3D12) (actual time=3D0.= 023..0.023 rows=3D0 loops=3D1)
=C2=A0 =C2=A0Index Cond: (pseq =3D '1= 400000224216382'::bigint)
=C2=A0Planning Time: 0.195 ms
=C2=A0Exe= cution Time: 0.046 ms

Any pointers about this woul= d be helpful.

Regards,
Ashish
--0000000000008ae815063f9e95f5--