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.96) (envelope-from ) id 1w627F-003sdc-1F for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Mar 2026 08:00:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w627D-008JHU-1i for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Mar 2026 08:00:23 +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.96) (envelope-from ) id 1w627D-008JHM-09 for pgsql-hackers@lists.postgresql.org; Fri, 27 Mar 2026 08:00:23 +0000 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w6277-00000001Hd4-1QfG for pgsql-hackers@lists.postgresql.org; Fri, 27 Mar 2026 08:00:21 +0000 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-38bf47a6f02so15567981fa.3 for ; Fri, 27 Mar 2026 01:00:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774598415; cv=none; d=google.com; s=arc-20240605; b=GZ96eJNDdGLmBvHA2nTT2Wzs2vzk8W9Dkw1hEPPB6CutIP2gjLPikYHlVqyWOOx4is FbE3QdBomz2DiCwhQJ6/rZRLFmMk2feGIZOJ1Xh4AR7v1EGmirGhHMrAJ6h+RmJOPgSZ fLsl3X5GgMxifHXnFTMIexvURS3dpkeGt2EdKuskiTd+hVsf79HGB5TqsuvpA+9u5lFZ ISioLyZ6WvSnjymNqf+3C/7W6JpbB/jQp03H7nElYEWmSNjNlKpIIBd2ITekxYxwC6yB DBD4NBaDr5DqUwbhNyyPP6iwq8/aBWmwiJnbKD7lEul1PHOWvV/LrtTofaOdtE93v+bI pYwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=gLyKgnmxWTiNnBXFaXicQSrGoVh8pV+IibJWwuaPlVk=; fh=8AIaMN4UjP9/6fTzrPBxeFOt3Nac2l70rAdsgsNYXI4=; b=L3rekT0n3mVddF6fh2T5hWfJ72o02p5uIrngbYNzeSFUCOg8jUfT7xd57t9szfniu8 48YIDQJ93QJwMHFcJzuxkZ3yI4uEJxAbr1VrFB25L9fEy5YbBqOKg7m1H1IfZyIWZ+ce bXeuh1qQSLnlv2g6o/hUCNgVWEq1sfwN7o6BlPHw3rk35Kxphamn38IcOJrDHzfsaP1T Go9K/OBcqLSANu7a17+ZGnTsLsU3SKwameE8xgk5oKOR7NiZU8gR9UINzpxeXHY6LZut +MITxjkrprEXiP73oEXkLHIDEC43hsedXRPBkGrfyoJuNDf6yr0YQkE+iGytsYUztToU svIA==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1774598415; x=1775203215; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gLyKgnmxWTiNnBXFaXicQSrGoVh8pV+IibJWwuaPlVk=; b=YhWX1orKYjNo9X0lySlMqmLdUn4PeMEj73OChJKz2KLdqfxUwgqotyn3SKbJ/ygSxi 6NORqnfS69uh7QbCwO+W5+IYbs2oYhymrsm0GV+i47VwWRe136mWh4u6RGTnJ3FWmpQj d7vqA87tuy4UKazdWkHuEJMbnwOfFK96jv/jGH45ZqpL0TbXzIGabb2RNFDNPdlInFeP uNDyyXADpqxHUu1xVjX6WA4rkx8IH5arouVplcsJal3naVE7wuWOMqTuHuEn++oq9v4P +HvajPswki6jdj/TSPqYC2U8n45WeBoHX17MJXs3rys1Ee36lT/ymhtTXsGZCa2Yro/q wjyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774598415; x=1775203215; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=gLyKgnmxWTiNnBXFaXicQSrGoVh8pV+IibJWwuaPlVk=; b=JYa5PfA3qTC1w69yVoHQdPqaP7AvzMEG7bKmnW5Mjz/8Nt9fQtl8kiVCAkuBSSakNA enDN75U6buHRrOYrZ7VdSeh1rpHN7ao3XO4BIXvtZNKyhMTjCbzV5V8NOqkSaPjl3x/t y9yiBIhNoj52nGuqg9j2y3YIjpxlUNj6A75psTomqJ9Tuh47V7SRilTvXma+31qUS1y0 nbFtIWP+1jSFZfYBm6rZkVFLPr0ZM4+sCeI9qF4IQ0Lp3Bx8BAO6jlS/Gf8TlQWazuVZ Q1J9QXTRS5fOSkTqp9BmOa/Mb1uZBXAzqtTexbG5iK/YtxNhkMTbzgAQ0ojEyHlnr64r eQAg== X-Forwarded-Encrypted: i=1; AJvYcCXnnmAAwQpKslrDBWWIB4v4/cGr3NGY9ctXN15Jskk4d3BlVSLOUiZI7sUDA50r9xytgysArAQyk5rQmoLQ@lists.postgresql.org X-Gm-Message-State: AOJu0Yxlw6iHPylC/ygu6DTuW33kvlSR0v2MEUkFYE1+6jHjKrKWXgdN F2S45/EbEfrITT1aaUDHt4exOraG2j7TfevCllGaEQeDLYg96ms9NilM2bCYhLiGva49tEkwH5H eGrMoKkkb6S86Ke6JBOqacak+3MRH5kqabSEG03TG X-Gm-Gg: ATEYQzwDaT7XEnCcByUdd8yhMvrf+hE8RjXiC7l0+te1kIcJaC5hbbstjfLq1QJNzQl mTQQghq/q9+0nrulDY32ko01zaPv17Iblxjy1WTJO6p7HBxrE0uuY31YHu04kuYZ65o63uAdiJ6 Dq1/qT+K3yIqcpnLCSI+9MvaJI276ybr2XNdDiyGvfvmSLLInj643kUrbMsWxUPdfw1R+A8Zotm fDb4f4/mG3JqyOGJPaAfB4HHIlHOjXV0WF47tL74jUA+ZcFwK/zF8btYsuwQUf9Po+5vvHPSaxe 9TW5rUkKB3AX1A1qKNjrQeR/voOVVic1d505mvf+ny2iZGWS9w8Umv6IsgPBuP/m/CbfULDAIbs iTg== X-Received: by 2002:a05:651c:41c9:b0:38b:f431:8135 with SMTP id 38308e7fff4ca-38c74072750mr5864111fa.35.1774598415280; Fri, 27 Mar 2026 01:00:15 -0700 (PDT) MIME-Version: 1.0 References: <1136161.1769654478@sss.pgh.pa.us> <1299934.1773938807@sss.pgh.pa.us> In-Reply-To: From: Jakub Wartak Date: Fri, 27 Mar 2026 09:00:03 +0100 X-Gm-Features: AQROBzAk58ttb4t72EGobNB3ETPtPjetv1K1OjjiJQtcq3o_YKQ4Bh2tLl6HPUk Message-ID: Subject: Re: pg_plan_advice To: Robert Haas Cc: Lukas Fittl , Tom Lane , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Mar 26, 2026 at 6:20=E2=80=AFPM Robert Haas = wrote: >[..v23] 0003: please be the judge here, as I'm not sure. Isn't there some too high concurrency hit in pg_get_collected_shared_advice? If I do pgbench -M extended -c 12 -j 12 -P 1 -S: progress: 59.0 s, 191008.4 tps, lat 0.063 ms stddev 0.200, 0 failed progress: 60.0 s, 197571.2 tps, lat 0.061 ms stddev 0.026, 0 failed progress: 61.0 s, 189825.5 tps, lat 0.063 ms stddev 0.208, 0 failed progress: 62.0 s, 197082.4 tps, lat 0.061 ms stddev 0.027, 0 failed progress: 63.0 s, 69345.9 tps, lat 0.173 ms stddev 1.651, 0 failed progress: 64.0 s, 47243.6 tps, lat 0.251 ms stddev 2.128, 0 failed progress: 65.0 s, 48211.6 tps, lat 0.247 ms stddev 2.156, 0 failed there is visible collapse from 190k to 48k tps was due to constant flood of artificial calls of: select count(*) from pg_get_collected_shared_advice= (); The code does LW_SHARED there over potentially lots of of tuplestore_putval= ues() calls. However any other backend does pgca_planner_shutdown()-> pg_collect_advice_save()->store_shared_advice() which is trying to grab LW_EXCLUSIVE lock, so everything might be be blocked across whole cluster? = (I mean for the duration of tuplestore entry and that seems to even talk about "tape"/"disk", so to me it looks like prolonged I/O operations for temp mig= ht impact CPU-only planning stuff?) Maybe it is possible to buffer those reads under LW_SHARED into backend-only (private) memory and later just fill tuplestore later to avoid such hazard? (but the obvious problem is how much memory we can have and how big shared area can become). Or maybe after some time simply release it and sleep and re-take i= t? 0004: question, why in the pg_get_advice_stashes() the second call to dshash_seq_init() nearby "Emit results" is done with exclusive=3Dtrue , but apparently only reads it? -J.