Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kwlnp-0001Qt-PS for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Jan 2021 12:51:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kwlnn-0001PG-EQ for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Jan 2021 12:51:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1kwlnn-0001P9-1a for pgsql-hackers@lists.postgresql.org; Tue, 05 Jan 2021 12:51:07 +0000 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1kwlnh-0007TM-JG for pgsql-hackers@postgresql.org; Tue, 05 Jan 2021 12:51:06 +0000 Received: by mail-wr1-x436.google.com with SMTP id r7so36044446wrc.5 for ; Tue, 05 Jan 2021 04:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jTs0wRAZzNdBoL/iFj6S4aTSUi0kxU1G7wuUw1/RG10=; b=J7NEjg6DHQKJQFffEByEt88elWYPIy3YCclMJ0vfkVEf768Zno9mbmtgZnliwgCWUT A+7aPoxkO019Gg+FK1TRc2SNfrEg24L4evwqWX4tJRxb/yrC/Qc4ggfKWRxyMGGPjPgR W30s7O/c2FMHjDP/+ZgAKR33C6+OvtFrWwLNXX+KYP6UOdawl6kcJTUbQ2JcNokgNVXc PUGvdH7kYhg8urTZpr7jQdzXF2fnA6RQZ08WnRnRm3ZGQARO5D9O3jfiHBRQew9R/qvf QN3SZh2e4jVZA3E6sUcdKWxr3atR6BzvVQEIKvwBdyGvqKnCIy5343Cqvjqq1plwSLa6 6YJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jTs0wRAZzNdBoL/iFj6S4aTSUi0kxU1G7wuUw1/RG10=; b=Kd43xQ6h0x30gCXyZBgVVd1JlWyE7D+G9yeIdCTYvsgNkxm09f8OQgoh+MKkad1/Of b91vJ/LIVIm8DHBCqqTp2O6JL+81achZm7FfyJbw/mWsfyWgeyLDrRxpFt2AdJsIJr2G pSs00WGVEjxw/363hLt404fP0UVNA+zLz73Lb1cweP17KONVymVuPKBm2q5Bl7zIR2Xt SspaNKFxG9lHD3Mnpk3VruQXn1e80Z8QlMAWZRQ9A/suiEx4LDMXWTMjmhfbGgVuQiqZ uhheOjAiEjVcChuTKT+GZ+zAbWLCA04vTRRIdrCPUab6rooVgqivHYkJ56LIgoKeMV92 9UKw== X-Gm-Message-State: AOAM530WHoSaLB8s8E3L88Oeo9seg9bHY5Nvt+vx6wE2EL+dqTaS3EP3 IQG3aEKpBt5t73DTB2804JM= X-Google-Smtp-Source: ABdhPJwivof1y2hL6dnlgBwv/HPuMAe5T1ttcxx9pWRJkEVsjiOvZ0tlVhz1sPpVpCwjZqZODcFrXQ== X-Received: by 2002:adf:ce84:: with SMTP id r4mr83358708wrn.91.1609851060335; Tue, 05 Jan 2021 04:51:00 -0800 (PST) Received: from localhost (dslb-094-222-016-204.094.222.pools.vodafone-ip.de. [94.222.16.204]) by smtp.gmail.com with ESMTPSA id s63sm4425055wms.18.2021.01.05.04.50.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jan 2021 04:50:59 -0800 (PST) Date: Tue, 5 Jan 2021 13:52:30 +0100 From: Dmitry Dolgov <9erthalion6@gmail.com> To: Zhihong Yu Cc: PostgreSQL-development , Tom Lane , Greg Stark , Pavel Trukhanov Subject: Re: pg_stat_statements and "IN" conditions Message-ID: <20210105125230.etgmgixnn6fmpszl@localhost> References: <20201118160432.hyko73sqc2bf7nkj@localhost> <20201226104635.uvzkftzu72zg5qux@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="oyjisgzd2vntjkkc" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --oyjisgzd2vntjkkc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > On Sat, Dec 26, 2020 at 08:53:28AM -0800, Zhihong Yu wrote: > Hi, > A few comments. > > + foreach(lc, (List *) expr) > + { > + Node * subExpr = (Node *) lfirst(lc); > + > + if (!IsA(subExpr, Const)) > + { > + allConst = false; > + break; > + } > + } > > It seems the above foreach loop (within foreach(temp, (List *) node)) can > be preceded with a check that allConst is true. Otherwise the loop can be > skipped. Thanks for noticing. Now that I look at it closer I think it's the other way around, the loop above checking constants for the first expression is not really necessary. > + if (currentExprIdx == pgss_merge_threshold - 1) > + { > + JumbleExpr(jstate, expr); > + > + /* > + * A const expr is already found, so JumbleExpr must > + * record it. Mark it as merged, it will be the > first > + * merged but still present in the statement query. > + */ > + Assert(jstate->clocations_count > 0); > + jstate->clocations[jstate->clocations_count - > 1].merged = true; > + currentExprIdx++; > + } > > The above snippet occurs a few times. Maybe extract into a helper method. Originally I was hesitant to extract it was because it's quite small part of the code. But now I've realized that the part relevant to lists is not really correct, which makes those bits even more different, so I think it makes sense to leave it like that. What do you think? --oyjisgzd2vntjkkc Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v3-0001-Prevent-jumbling-of-every-element-in-ArrayExpr.patch"