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 1kfPvr-0006mu-L3 for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Nov 2020 16:03:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kfPvq-0004FC-JW for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Nov 2020 16:03:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1kfPvq-0004F5-3U for pgsql-hackers@lists.postgresql.org; Wed, 18 Nov 2020 16:03:42 +0000 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1kfPvm-0002Hl-K1 for pgsql-hackers@postgresql.org; Wed, 18 Nov 2020 16:03:41 +0000 Received: by mail-ed1-x52f.google.com with SMTP id a15so2574698edy.1 for ; Wed, 18 Nov 2020 08:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=pHectW+1I3Bvw/aYUmtYokc++TT3wYzk8iR7j2btc2k=; b=gH4JkodYZMsR2tHNXXf1xMrSRU7w3Clunezcd43LI9F1P41AUVSIV4nOg1kV07xLIs vEdjg5635Z5aigPYwmzxjuoTLwif81WGhH70kSV0iZ1tV2czMYM9u69naWewMqcAF3+A fof6NFK7YecEHyHf9QKFxegK3uvn0+6Q0gS9NZf7ug42Sr1jFz1SE/nQsc54cSLM1uoO UkrQdt3TaaREoEhFmMZTU+C6jHE5vqzqfQlCNYW9gXgvbV2O7D5eyW40KeBZQfEsKOu7 NnlkGaKcpbYJCxlg4X4kcBoWkjVKZ4u9xNQwrsyoRu+mgLfB7CfY/jRyGvU+DAAohziD aTBg== 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:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=pHectW+1I3Bvw/aYUmtYokc++TT3wYzk8iR7j2btc2k=; b=TuyvBdRsTm1aKwog8GvYKY3ehkO/zOj/0kFtflJwoYIVlwQeWxtegfPFuHTm4se0vT FaZXO/STTfPKbpFKZnPfhgh3wkw8KRNzZ/WVMF8BepkJAClAvyIQG7UQ+QoPHaaha+MW qTOqDpxfkmpLuJ169YO6qD4mxLCzL+mthuL3/0VqiX4nKe4uDq3CRpQpx7LrTJ+nwEWQ 2hfkvybdqu82rcjyzDv6ZjC0GYZQtMu12LGNVqC8PAEs5HY/NVfNn3SFt60vo+xDM3YI Trqs9I0BxLZqM1+ZOCSASSyqH9HNgIzXPgBKnzC4DMWvyFVGoE/UfzxFrgY4oLO8KB0z /a6g== X-Gm-Message-State: AOAM532a6ec7JMGupMpQ5Vpudrrbv7FiIC9DF6OpkAIo/bKTl955sNUU gaEqPVHm6I15iR2/+c2NEaVWoSWK9GeAeg== X-Google-Smtp-Source: ABdhPJyP3z6PJHVN4f/y1nLppxeSxXtudfenELC19I8JvGl86Pyuim2KTlVk2QJac83LgdR62XFNHw== X-Received: by 2002:aa7:ccd2:: with SMTP id y18mr26744569edt.11.1605715417038; Wed, 18 Nov 2020 08:03:37 -0800 (PST) Received: from localhost (dslb-188-102-101-219.188.102.pools.vodafone-ip.de. [188.102.101.219]) by smtp.gmail.com with ESMTPSA id e10sm13581436edq.55.2020.11.18.08.03.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 08:03:35 -0800 (PST) Date: Wed, 18 Nov 2020 17:04:32 +0100 From: Dmitry Dolgov <9erthalion6@gmail.com> To: PostgreSQL-development , Tom Lane , Greg Stark , Pavel Trukhanov Subject: Re: pg_stat_statements and "IN" conditions Message-ID: <20201118160432.hyko73sqc2bf7nkj@localhost> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5c7h2kpuhhknl5pq" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --5c7h2kpuhhknl5pq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > On Wed, Aug 12, 2020 at 06:19:02PM +0200, Dmitry Dolgov wrote: > > I would like to start another thread to follow up on [1], mostly to bump up the > topic. Just to remind, it's about how pg_stat_statements jumbling ArrayExpr in > queries like: > > SELECT something FROM table WHERE col IN (1, 2, 3, ...) > > The current implementation produces different jumble hash for every different > number of arguments for essentially the same query. Unfortunately a lot of ORMs > like to generate these types of queries, which in turn leads to > pg_stat_statements pollution. Ideally we want to prevent this and have only one > record for such a query. > > As the result of [1] I've identified two highlighted approaches to improve this > situation: > > * Reduce the generated ArrayExpr to an array Const immediately, in cases where > all the inputs are Consts. > > * Make repeating Const to contribute nothing to the resulting hash. > > I've tried to prototype both approaches to find out pros/cons and be more > specific. Attached patches could not be considered a completed piece of work, > but they seem to work, mostly pass the tests and demonstrate the point. I would > like to get some high level input about them and ideally make it clear what is > the preferred solution to continue with. I've implemented the second approach mentioned above, this version was tested on our test clusters for some time without visible issues. Will create a CF item and would appreciate any feedback. --5c7h2kpuhhknl5pq Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v1-0001-Prevent-jumbling-of-every-element-in-ArrayExpr.patch"