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 1tSOhN-00GCFo-Fd for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Dec 2024 22:57:22 +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 1tSOhM-00FiJi-Q8 for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Dec 2024 22:57:20 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tSOhM-00FiJY-Dz for pgsql-hackers@lists.postgresql.org; Mon, 30 Dec 2024 22:57:20 +0000 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tSOhK-001JvQ-0v for pgsql-hackers@postgresql.org; Mon, 30 Dec 2024 22:57:19 +0000 Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5d88c355e0dso1053031a12.0 for ; Mon, 30 Dec 2024 14:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jeltef.nl; s=google; t=1735599436; x=1736204236; darn=postgresql.org; h=in-reply-to:references:from:to:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Ajr3O7qeJ6wbni90RqKFNcUMV3PwSzy4KTU+WjjqtR0=; b=WkV844djYFTxzaIggTFDDbKICYkSHowqthNUV5sMjuFyz5FxJ8YxO1hr1pSKaWwqLK Os7x3WvEf+MkHVfRRLgCGX1gZgqIlbaB2A3pDSB43QjzAO8qparKTtrWnkdq527iceVE cLN9pt+kxdbJAvX6d+OLkgyCRmuQ2CJPuV06k/fDL2sfT0Nwwd5M1oV6NNkKrBTLAn+2 MaUdeXawTcI9bVFjlYONKHwzTa2ZAruvRzTR4A2JPEkQ2oDvhX8/oFHv50kxjeVygmtS 7cNUQ7uL/BkOhpSay0rxMjRKvv38/v7XlmAg6JlCRcDOXBz3vWqux0FfutHe1o712ZEr APYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735599436; x=1736204236; h=in-reply-to:references:from:to:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=Ajr3O7qeJ6wbni90RqKFNcUMV3PwSzy4KTU+WjjqtR0=; b=OXYmne+iy01rGguTAih4pBEeMLkzwUGiPoP43ZW0Pa3lXvHfKz1nklf3Q/AFufP0oU NcGMShq0/nwE662XRm9m1K4I3bkPOv2G4Fcwuuc+RDlR4TxXv475V08vsiYCQmyAzLGE +bkXuPDVpDsGwXwKraKcep6qNDK8RdTczMjlCU9ULbXzlJEzJ0K6KaUZhAlyDf4dqYRH aBryzsoYm9qh9mY5u9HQzUtTCNme9Ayrb1yt2koPTBYXj2xKRBRVv+v2uI0+LpGMFbV9 cXaftwgozwE78C39lva5AwjNPYtpaF4xVEF2zkNZobbsHuOnVkgamdnE9GKYI/Li+O+6 8Apw== X-Forwarded-Encrypted: i=1; AJvYcCXk7K2cvzC3KHBDK8Y186TGYQieYXTHDLeAwbVYb4FrvTw8u1M+n5R2O2hYDVtJ/esrBOrSmWSXMgSbGm7P@postgresql.org X-Gm-Message-State: AOJu0YzJ7jD/GhjmKRsrItqh7JSPFTlJ6EFFtu/hIU/ljQIcg6S0m3U2 P7WSJT2xCAerJh1ROoiNArHZz/IDa9sczvZPS2MXqjR0kmsHZm0E2VtuXd3CDPI= X-Gm-Gg: ASbGncs/kGuGZFKXAl0PWdNON+DmZfcbjJ94PyOCFQkv6Wq4qXu1gZqVINpcUfy13Vo w99sva8I2MHHX8LNT0T+BI0asQU8QsL+Jwa7XuinTZ1xFwwgC118Gj+yOehIIImbhj00KGAsF+X F28rGfUvOoEFiXvldQ4mDV7jMUQmqu1luYVrbbqLyIBI/YMR8Mm/YhOcyfwaoddNssRgr0I9AJ3 J3I1UUpf7E7ph+C5ZMdx7ypMsERr0HLt+P4U+eI/X2kApsZ8Fjlflj4o0hrnOLoFkFbVyp6JZ7n xQr0Ng== X-Google-Smtp-Source: AGHT+IHF6+MRaZFkqbrVoVeDrAsQAa5tycjITgspF91fT/+OaGjNMgtWTQTmabwMXCxNT6LObn4gOA== X-Received: by 2002:a17:907:7f91:b0:aa6:ac4c:8dc with SMTP id a640c23a62f3a-aac2ad81a0cmr3142626166b.18.1735599436238; Mon, 30 Dec 2024 14:57:16 -0800 (PST) Received: from localhost (145-53-221-196.fixed.kpn.net. [145.53.221.196]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0e82f178sm1504417966b.38.2024.12.30.14.57.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Dec 2024 14:57:15 -0800 (PST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; format=Flowed Date: Mon, 30 Dec 2024 23:57:14 +0100 Message-Id: Cc: "torikoshia" , "Pgsql Hackers" Subject: Re: RFC: Allow EXPLAIN to Output Page Fault Information To: "Tom Lane" , "Bruce Momjian" From: "Jelte Fennema-Nio" X-Mailer: aerc 0.18.2-131-g6c17c2000fa3 References: <1614321.1735055528@sss.pgh.pa.us> <3861403.1735576764@sss.pgh.pa.us> In-Reply-To: <3861403.1735576764@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon Dec 30, 2024 at 5:39 PM CET, Tom Lane wrote: > Bruce Momjian writes: >> I certainly would love to see storage I/O numbers as distinct from >> kernel read I/O numbers. > > Me too, but I think it is 100% wishful thinking to imagine that > page fault counts match up with that. =20 Okay I played around with this patch a bit, in hopes of proving you wrong. But I now agree with you. I cannot seem to get any numbers out of this that make sense. The major page fault numbers are always zero, even after running: echo 1 > /proc/sys/vm/drop_caches If Takahori has a way to get some more useful insights from this patch, I'm quite interested in the steps he took (I might very well have missed something obvious). **However, I think the general direction has merit**: Changing this patch t= o use `ru_inblock`/`ru_oublock` gives very useful insights. `ru_inblock` is 0 when everything is in page cache, and it is very high when stuff is not. I was only hacking around and basically did this: s/ru_minflt/ru_inblock/g s/ru_majflt/ru_oublock/g Obviously more is needed. We'd probably want to show these numbers in useful units like MB or something. Also, maybe there's some better way of getting read/write numbers for the current process than ru_inblock/ru_oublock (but this one seems to work at least reasonably well). One other thing that I noticed when playing around with this, which would need to be addressed: Parallel workers need to pass these values to the main process somehow, otherwise the IO from those processes gets los= t. For the record, the queries I used to test this patch were: create table t_big(a int, b text); insert into t_big SELECT i, repeat(i::text, 200) FROM generate_series(1, 30= 00000) i; explain (ANALYZE, PAGEFAULTS) select max(a), max(b) from t_big; explain (analyze, PAGEFAULTS) insert into t_big SELECT i, repeat(i::text, 2= 00) FROM generate_series(1, 3000000) i; And then seeing if there was any difference in the explain analyze output after running the following (as root): echo 1 > /proc/sys/vm/drop_caches