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 1p0BDF-0002Wu-BD for pgsql-performance@arkaria.postgresql.org; Wed, 30 Nov 2022 00:44:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p0BDC-0007vN-Pe for pgsql-performance@arkaria.postgresql.org; Wed, 30 Nov 2022 00:44:30 +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 ) id 1p0BDC-0007vD-EW for pgsql-performance@lists.postgresql.org; Wed, 30 Nov 2022 00:44:30 +0000 Received: from mail-qv1-xf35.google.com ([2607:f8b0:4864:20::f35]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p0BD8-00010m-0M for pgsql-performance@lists.postgresql.org; Wed, 30 Nov 2022 00:44:29 +0000 Received: by mail-qv1-xf35.google.com with SMTP id e18so9593813qvs.1 for ; Tue, 29 Nov 2022 16:44:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:references:in-reply-to:date:cc:to:reply-to :from:subject:message-id:from:to:cc:subject:date:message-id:reply-to; bh=cxPZVV9tdIWiZT0RMZn50Lhx4wdCqwUs5xx5ZPYq21c=; b=c5TFPIC3h5g9PLlljCiOWPMmqebT2u1/f3bt8rJrEz6Jh9SUeMIuT2GtQq26h2M58I 0zBJo5m8Wvi6lk5UZ6eqCLPY1p4JhsTie7pXlvSRTUc6E0m8LuyFHMe7d2KkqJY9WATV 9qZV/IQ3W9X94oBupzG5KhX19KKNyf/G07gw29Mtv45K8SNUSwqUerdsWQnoPe6o9/xe iyBk+Bu4XG8IIAjQJro6KZoIOq9KbXLlI9ivPCVdHjSTDEIOM+4uLeXhyOFdjOCcxYbO srKJ3TtZDUwGaqVDsZGWwijNc/3+ZqwEuIygD+j7WiU+y/C4stxAGH3lXIlWaZMWb5N5 tolA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:references:in-reply-to:date:cc:to:reply-to :from:subject:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cxPZVV9tdIWiZT0RMZn50Lhx4wdCqwUs5xx5ZPYq21c=; b=GWDrawntlaMJ5ofLSDUQzxxOEE35SVR0FZhL275UHOVrHgX3on9iYmfIW8rsqP0PZp a/xFGLK5hC2fHbHrydNeg4UIIurMQUPyCPMPoIhLGofUi9NVBdQf9fsDpVf62CCz9xzl Lr1EcdzgHw7Dc5rDIsW9HSx48pa/TetjqJEx0ROF7OnVmD6EWxUfNBq5h2alJzertDLr gFe1GTAiSRuScoqrDI/widhREdT5JFwhewlcSZ+6xceWSIB09Fu6RWZ1Je9R1gL0mhE3 T2ukf8NJxfUoEfLBdvTvKq265bxz6x8DOuptnPUNa1vQZNgp4cV63FvKsfdYiitnADuL 6HZA== X-Gm-Message-State: ANoB5pkC9Y0ArVQ6OxiuclfmLwanTbMTUy/JdzOmgPvNqfmiaHxGCBMW x0N5jJEE/RYT1GZAw2JEcSeyNQxJF2bjDA== X-Google-Smtp-Source: AA0mqf4xxghramCkjUaQaIM5X0rite4n9WBvRVp97BVIQ7l6j74UyIK7K4359HkRfC6d9esOoDV6zw== X-Received: by 2002:a05:6214:3307:b0:4c6:9c02:5ab with SMTP id mo7-20020a056214330700b004c69c0205abmr36626261qvb.65.1669769064823; Tue, 29 Nov 2022 16:44:24 -0800 (PST) Received: from [192.168.2.100] (pool-72-79-30-4.nwrknj.east.verizon.net. [72.79.30.4]) by smtp.gmail.com with ESMTPSA id o11-20020ac8554b000000b0039cb59f00fcsm9419723qtr.30.2022.11.29.16.44.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Nov 2022 16:44:24 -0800 (PST) Message-ID: Subject: Re: Catching up with performance & PostgreSQL 15 From: Mladen Gogala Reply-To: gogala.mladen@gmail.com To: Alvaro Herrera Cc: pgsql-performance@lists.postgresql.org Date: Tue, 29 Nov 2022 19:44:23 -0500 In-Reply-To: <20221129180914.pdrqrbqtls3g6yoq@alvherre.pgsql> References: <20221129180914.pdrqrbqtls3g6yoq@alvherre.pgsql> Content-Type: multipart/alternative; boundary="=-8Kw0Z9dGgAsBeUVbrmRF" User-Agent: Evolution 3.46.1 (3.46.1-1.fc37) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --=-8Kw0Z9dGgAsBeUVbrmRF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2022-11-29 at 19:09 +0100, Alvaro Herrera wrote: > On 2022-Nov-29, Mladen Gogala wrote: >=20 > > Hmmm, I think I will run pgbench with and without JIT on and see > > the > > difference. >=20 > I doubt you'll notice anything, because the pgbench queries will be > far > below the JIT cost, so nothing will get JIT compiled at all.=C2=A0 Or are > you > planning on using a custom set of queries? >=20 Nope. I am planning to set jit_above_cost parameter to 5. That should take care of the pgbench problem. Other than that, you're right: JIT should not be used for OLTP. However, pure OLTP or DW databases are a rarity these days. Reporting is a crucial function and almost every OLTP database that I've seen also has reporting function, which means that there are complex queries to be executed. --=20 Mladen Gogala Database Consultant https://dbwhisperer.wordpress.com --=-8Kw0Z9dGgAsBeUVbrmRF Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
On Tue, 2022-11-29 at 19:09 +0100, Alvaro Her= rera wrote:
On 2022-Nov-29, Mladen Gog= ala wrote:

Hmmm, I = think I will run pgbench with and without JIT on and see the
= difference.

I doubt you'll notice= anything, because the pgbench queries will be far
below the = JIT cost, so nothing will get JIT compiled at all.  Or are you
planning on using a custom set of queries?

<= /blockquote>

Nope. I am planning to set jit_above_cost p= arameter to 5. That should take care of the pgbench problem. Other than tha= t, you're right: JIT should not be used for OLTP. However, pure OLTP or DW = databases are a rarity these days. Reporting is a crucial function and almo= st every OLTP database that I've seen also has reporting function, which me= ans that there are complex queries to be executed.
-- =

Mladen Gogala
Database Consultant

--=-8Kw0Z9dGgAsBeUVbrmRF--