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 1tOy0e-009Lwa-1y for pgsql-performance@arkaria.postgresql.org; Sat, 21 Dec 2024 11:51:04 +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 1tOy0b-007ynr-It for pgsql-performance@arkaria.postgresql.org; Sat, 21 Dec 2024 11:51:01 +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 1tOy0b-007yni-6u for pgsql-performance@lists.postgresql.org; Sat, 21 Dec 2024 11:51:00 +0000 Received: from mail-yb1-xb29.google.com ([2607:f8b0:4864:20::b29]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tOy0U-000uUi-Dx for pgsql-performance@lists.postgresql.org; Sat, 21 Dec 2024 11:51:00 +0000 Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-e3fd6cd9ef7so3134091276.1 for ; Sat, 21 Dec 2024 03:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734781852; x=1735386652; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=waXj/N7HZoq+rQYDikwFvRp6dK2kZMiWKSd64QE49SM=; b=lHXzBgObe3rFg9u1rC62CY36qgALMAFUEVMmSvPLrOAt39VpTqQyGFKM+FDWFG6sOK 0UEbu0y7RkLldr6ZY1XU0Oa6PO11cWPLqAQJrSDoY7/TYMegFebr+sxIPp5xecwfBW5f GYJmGoPxJdFj+LlOHE/E9KjXqrC//yv+rVf27oVtEKdIDmm1C+5NtmZdt9JlyBg3dT9M u/CTZiKxFLCCPzBFgwfgucAdLki0CK9VVNmvjjXlaADQrLfT+8KXgUY57vW3xm9EFNqY 8jIO21r+PZJyip0MTPSUD0U43s5/YX40zUI84wOxKhCP3R/R0IGbZafQkmxAQlbNtDMR YZaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734781852; x=1735386652; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=waXj/N7HZoq+rQYDikwFvRp6dK2kZMiWKSd64QE49SM=; b=sN2xOMVxnu1yqD+tAYIxb2M6r/2g1TFI/aDcQjksAmPblnLh7IC9e5QGCQavo6nIAi zksymPGwYp4lKWhJrVJj3t69hjy2NkoTUci1pKTZtltG1iFIQCnm7mzz+celIw+OK91G k7ZPJy/gJUVGHnPb0wphtkRMB2kvEsh9GDp06u7WYpS6g89xUOGUxjcw5uIswQvChmoC Z9uTi9IMU3rgFOUyvccvExI5O7dfzcXAR0rYKkS1+880n+mba+NLFsR0+3TkP3rIeXeu cIpJ8F3GwTdpkGhxfcA2+oaQFw9kL6FPIqxKs2APHcf3rI1Dd3d+y9/FoLkwbh2eDdUv gwNw== X-Gm-Message-State: AOJu0YwZKLAUDhQvkJWB7MkZeQS6f3BvXSZl+sWceUOESX7UZimrvmsH WIj6MNbCSJv4w/3qaDZR9MicGDiwQIzBlY/3gDuQSEpn5omwk8FbBekuEgkI1TDhwPxAOFDkfoT hx22TQZQ3BSoau1pcxE3Fv6oAo9+pS8Mr X-Gm-Gg: ASbGnctNpPAmYi+9iQ2jA4ushx4FbvaSQMfmiSptHlfiG4q/IO4hpRIrLL10LXdwY8S syvUR1KG1gNi/tnqSAyHNUmIlLtOip0N8tLZY X-Google-Smtp-Source: AGHT+IHSFO7JcYoY4diQwUsueJF0EUxtEch5z/cavmWQofEtflzLUtP/4JxNbGay2wIUE0MZRc7SFtyOWhbdPQDjvXM= X-Received: by 2002:a05:690c:c07:b0:6f0:697:da5f with SMTP id 00721157ae682-6f3e2b6bb89mr80339607b3.14.1734781852576; Sat, 21 Dec 2024 03:50:52 -0800 (PST) MIME-Version: 1.0 From: James Pang Date: Sat, 21 Dec 2024 19:50:40 +0800 Message-ID: Subject: huge shared_blocks_hit one select but manually run very fast To: pgsql-performance@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000015f4760629c660aa" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000015f4760629c660aa Content-Type: text/plain; charset="UTF-8" Hi, we have a simple select .... from table where ... (that mache the index) , table has 80million rows. when many application sessions run the query and at the same time some other sessions doing insert into ... this table. from pg_stat_statements, shared_blks_hit show 31652 / per call. we see very high cpu almost 100% cpu during application workload test, and high LWLock BufferMapping waiting for these querys. But manually run the sql show only 2148 shared_blks_hit/ per call. this is a simple sql, from pg_profile we did see it use same index scan as manually running. What could be possible reason leading so big difference with shared_blks_hit ? PGv14.8 Thanks, James --00000000000015f4760629c660aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0
=C2=A0 =C2=A0we have a simple select .... fr= om table where ... (that mache the index) , table has 80million rows.=C2=A0= when many application sessions run the query and at the same time some oth= er sessions doing insert into ... this table. from pg_stat_statements, shar= ed_blks_hit show 31652 / per call.=C2=A0 =C2=A0we see very high cpu almost = 100% cpu during application workload test, and high LWLock=C2=A0BufferMappi= ng waiting for these querys.=C2=A0 But manually=C2=A0run the sql show only = 2148 shared_blks_hit/ per call.=C2=A0 this is a simple sql, from pg_profile= we did see it use same index scan as manually=C2=A0running.=C2=A0 What cou= ld be possible reason leading so big difference with shared_blks_hit ?=C2= =A0=C2=A0
=C2=A0PGv14.8=C2=A0

Thanks,

James
--00000000000015f4760629c660aa--