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 1tfS8J-002UnY-7Q for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Feb 2025 23:15:07 +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 1tfS8G-009eyS-WB for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Feb 2025 23:15:05 +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 1tfS8G-009eyJ-MU for pgsql-hackers@lists.postgresql.org; Tue, 04 Feb 2025 23:15:04 +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 1tfS8D-003Jtr-2L for pgsql-hackers@lists.postgresql.org; Tue, 04 Feb 2025 23:15:04 +0000 Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-3043e84c687so52071911fa.1 for ; Tue, 04 Feb 2025 15:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738710900; x=1739315700; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SJfvmOpxgQG02rG2EdAb1dn27BslAgz0TH+HWwsnuDA=; b=e8MKCWH9TRNGcAna2cktrg67XGwblq19GNQrS1T8yRoPhgokxsKv0b/TcAvj1TgxnB DigwH73c1MvSxjm3jxs4Kyr9KLDp6vIouygbEYf9trSdxcFMHLUd5ZFFehL29q4vyMBO hJgeKh3qZvL3c2hH6ET/ocAVQrQ6pGlrahts0habZjVs2mo+GKsJDQb1TRCPll2VUdgQ Iaoc2I+DcMs2jnMW0WsYlbL4l91FiUsNbcR9+T2BXvoqutrQqO6vBUTrhJ1U6003KdvO ouPX9FX0NuvlQ1+/23haOXVQRrsRMA9MI/ILvACqzvmXoOjpUrvI3hCuhOOcZJSJNmqp l1Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738710900; x=1739315700; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SJfvmOpxgQG02rG2EdAb1dn27BslAgz0TH+HWwsnuDA=; b=iwaK3em4nrxiZ5sUOvVbDYZdhol1TDLyxskIQkvQIdTNylKu4cOuOW/36Ish2PHuCo yenRu/r7zJQOIhooC+7gfYG6srqTXBLc12F2KfD/PnngFInNjEvXQDkAEmmCBU8DZbXg 8CW/KM7PYcusmN/MT4H9mPYuqwqzg7BsmUW3B958D60BvGgQzq6SB5aUtqL0PQFweABi MlnQf73vdI1EbB/qe+lSBBWnVaK+huS8Oedv6WDMuBVd9FTZnvKFV3AWNgEJotYi/0pu pcI//TqqysXEbL6ki2IpYGwLgC6dckBd/diCug+tzOGwzE+3/nJM7lSXQYpW5HipCzTK TJ8w== X-Forwarded-Encrypted: i=1; AJvYcCWrQ4+lZUfMZhpHW5dQuhz3GQLt/2IoqpxaXgcuK0cuiYWxsz3Fk4ceGXQDwWZ3bnJISC4fqfn/A2RIpuJm@lists.postgresql.org X-Gm-Message-State: AOJu0YwBdS+TAspYVL3qlBOuT8UBblJPLec61BuYhnwG8MzglppR2tC9 1xSeDIGHfzw6bwLc69hZyQF9Lh4DyvNbxeX3zQTueTPjqrC8fDd5qw2G9UbosFYXpq/z9LDw6II yD7565y+tGasocPSnAfUet6PeCzAA9zNK5rA= X-Gm-Gg: ASbGncuNilTlOkVTgWqWyu76NswHZIKC8uOXWS7ENO2DiBhumzCceeGImzpCyDA85wK xNrCRStVWvyuMeKujNDu35gn/KGMu/0fNCzTOnPH9cotWo1A3f+5YVuAcUf5hZ57CtRc5zTU= X-Google-Smtp-Source: AGHT+IHGrWPjIMi7SkkAlmWJPJJqhweW0W9S2/IgJM+C6do6vBiDaxEMma6ZIzlcR+93drbdZVplFvs8bo8CcXv480A= X-Received: by 2002:a05:651c:220e:b0:2ff:d7cf:a6cb with SMTP id 38308e7fff4ca-307cf2fdd34mr2483221fa.11.1738710899937; Tue, 04 Feb 2025 15:14:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Sami Imseih Date: Tue, 4 Feb 2025 17:14:48 -0600 X-Gm-Features: AWEUYZlJlK4NYLVTtpbH56Jv8L15DsC3vEh1ynNSgTUec_eqQHBsM4dHlVa8gII Message-ID: Subject: Re: [PATCH] Optionally record Plan IDs to track plan changes for a query To: Michael Paquier Cc: Lukas Fittl , PostgreSQL Hackers , Marko M Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk >> Separately I've been thinking how we could best have a discussion/review on >> whether the jumbling of specific plan struct fields is correct. I was >> thinking maybe a quick wiki page could be helpful, noting why to jumble/not >> jumble certain fields? > Makes sense. This is a complicated topic. +1 for the Wiki page I started looking at the set of patches and started with v3-0001. For that one, I think we need to refactor a bit more for maintainability/readability. queryjumblefuncs.c now has dual purposes which is the generic node jumbling code and now it also has the specific query jumbling code. That seems wrong from a readability/maintainability perspective. Here are my high-level thoughts on this: 1. rename queryjumblefuncs.c to jumblefuncs.c 2. move the query jumbling related code to parser/analyze.c, since query jumbling occurs there during parsing. 3. Rewrite the comments in the new jumblefuncs.c to make it clear the intention of this infrastructure; that it is used to jumble nodes for query or plan trees. I can work on this if you agree. Regards, Sami