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 1rAClw-005Nrn-Vb for pgsql-performance@arkaria.postgresql.org; Mon, 04 Dec 2023 17:30:21 +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 1rAClv-000ZeU-Kj for pgsql-performance@arkaria.postgresql.org; Mon, 04 Dec 2023 17:30:19 +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 1rAClv-000ZeM-AP for pgsql-performance@lists.postgresql.org; Mon, 04 Dec 2023 17:30:19 +0000 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rACls-00A5RP-K5 for pgsql-performance@lists.postgresql.org; Mon, 04 Dec 2023 17:30:18 +0000 Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3334d9b57adso642980f8f.1 for ; Mon, 04 Dec 2023 09:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701711015; x=1702315815; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=mg13B0FjawYn+ipOF/FV9FpweNfCH1MYWDmqbba08mc=; b=k/K3HBaQqQkxZboZA6uucTdp11Lu7aoLOyiUeaFFOEAYuHt23+o1GfEN2s3B+jUD+z wcGUA0C4DvcbVmLloeOkJn+kUv0PwgTYTIwrmUHN3YCjkCi6kvhuhWm14pIJxpkWwbc6 FhP3Sldq3ub+ru05ixIJ2cKvnb4jimqJXxPMrYq6FNO737jr1snNVNfuJx210DZ4OE/i Sh5SBfgJpCebXWG3R0ZM3ccvmrFouk8hDafH1lpdwAO/8TP9KcFNCBqhALfH7V7RVKhC 1tt5xWV+rGlXJHZ3FKKo4I3JQgBn2uXj+CsSYTI0hZ+jncNliYXtrQCld4WH6BGV+MrJ 6Hlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701711015; x=1702315815; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mg13B0FjawYn+ipOF/FV9FpweNfCH1MYWDmqbba08mc=; b=FVwbX2YB24i6jYY4pv/uuKWBKokVmGy8MO4VFHK6UkEB2vlbDcGklNd/Z0tQlEMe3V mZAogYRj3xVPNq1m+/XwzlE6nPN/t6H5Ko4afAVONwD8LRJqXQJn7N9yrqs9KQZs+mp+ vMU2RF1lu6c8fAynrW1VbI4rPd0DoPOf8TzmkGNLKnrJJS5wx7jwAFbOre2shAy8XNXA 4+NGbXHTAgWNNyJB9JS4L2ghUIAyZ8eXghrmdeNCPvokB8df2M+/dG+n0yxq0Sp+57on wE3vCHXdlDLq4XyMrWf12RSZY9E2Lk3A+hinBFktAgvg7hqQMjzMq+kbK4eZEZov+IFl L0Ig== X-Gm-Message-State: AOJu0Yzh7fNkEohLKfNjzHzBxqRNRnoBNrpuWY5jR69w/VrZB8JgQRYW lTZbL8jS022n2Rr4qWSuqNQ= X-Google-Smtp-Source: AGHT+IE/5WNAOrHvKcugRGaC6V3t6TXyxbEk0YZysSFuLfq9CMOV5KaMb8m7KyYhUYsmTBMukWXPwg== X-Received: by 2002:a5d:540b:0:b0:332:e733:b9a4 with SMTP id g11-20020a5d540b000000b00332e733b9a4mr3207341wrv.53.1701711014934; Mon, 04 Dec 2023 09:30:14 -0800 (PST) Received: from jrouhaud ([2a01:e0a:c:bcf0:65e2:bd83:f602:5753]) by smtp.gmail.com with ESMTPSA id c8-20020adfe708000000b003332aa97101sm11204449wrm.38.2023.12.04.09.30.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 09:30:14 -0800 (PST) Date: Mon, 4 Dec 2023 18:30:12 +0100 From: Julien Rouhaud To: Jerry Brenner Cc: pgsql-performance@lists.postgresql.org Subject: Re: Does Postgres have consistent identifiers (plan hash value) for explain plans? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Mon, Dec 04, 2023 at 06:45:39AM -0800, Jerry Brenner wrote: > We are currently on Postgres 13.9 (and will be moving to later releases). > We are capturing json explain plans and storing them in a database table. > We can tell that there are different plans for some queries, but that's a > very labor intensive process - we'd rather do this using SQL and comparing > consistent hash values for the plans. Both Oracle and SQL Server have > consistent hash values for query plans and that makes it easy to identify > when there are multiple plans for the same query. Does that concept exist > in later releases of Postgres (and is the value stored in the json explain > plan)? > > While we have a pretty good idea of how to manually generate a consistent > value, we don't want to reinvent the wheel. Is anyone aware of an existing > solution that can be called from SQL/jsonb? You can look at pg_store_plans extension: https://github.com/ossc-db/pg_store_plans, it can generate a query plan hash and also keeps tracks of the (normalized) plans associated to each (normalized) query.