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 1oPw3R-0005BN-2q for pgsql-admin@arkaria.postgresql.org; Mon, 22 Aug 2022 01:16:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oPw3P-0003pc-Ic for pgsql-admin@arkaria.postgresql.org; Mon, 22 Aug 2022 01:16:35 +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 1oPw3P-0003pT-6C for pgsql-admin@lists.postgresql.org; Mon, 22 Aug 2022 01:16:35 +0000 Received: from mail-qt1-x834.google.com ([2607:f8b0:4864:20::834]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oPw3M-0005HX-NH for pgsql-admin@lists.postgresql.org; Mon, 22 Aug 2022 01:16:34 +0000 Received: by mail-qt1-x834.google.com with SMTP id j17so6916168qtp.12 for ; Sun, 21 Aug 2022 18:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc; bh=m33eOPf0Se5py9aGBQY5T+/QRdIcidn6hUsH7pSw+dY=; b=ABfc9p1ECMtRoj5p21tEoRoWHZG+ivjStZP2W8Ob+cZwPU2KaZ+CL3ScsgRz5klABd +jkzIutF1eJBJu1Unicy0Jbcm1a7m8vGRXUH8rh1WyEc7Qrw8mX588iFVYkXVU0Gss0U 3K3ZKOBMBV05NkYE0cPFM9gnlu/khrcodT5rCOY7mthINdpV2vPBxYkA8f8ab7eTLHgj qvARXg1txI5lUdv6IGW7rUc2Ujh0CRR/3JkHI8ZD2Y5tiF1PagkFKEuRTk9NUGPRZbIx IuaHi/lACSmaEJyyZwAQm0JxWqeMFyNQ9ZD+MrjqB5tmFFLziKwCxVlbDZJZI4NCk60q XPhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc; bh=m33eOPf0Se5py9aGBQY5T+/QRdIcidn6hUsH7pSw+dY=; b=HzzV5/ozSJJTdMrVYe+IyaIw6ItsGIo+4TGIKMYFEExdt4GHIJ6TjUxDWLcaOx0tqH s6vTiDccqZGTS+P4YStGspuKHc9jXBto7pQrOvn7y7RJZpHHK3h/UbmDqDtbp35YuzHD LDKBSHZWzO8dGHvTyxJG9+EP85VQZYdM03GcoZff0fyInExQwzkoCG3FQGUEIT2Kvz8K iF56uh7b7L6xh2Vb4fq0pCB5qVNbAYqo79qdxLAeWHEDgrlo1mlvaGpdoStMQYpT/NCI 40eTGrRrQu8P5z8bpWxW12QEnzQbUANEBmV45WgluRfMf6mh7SbVQSzEm7XIQU/jXKYp b/Ig== X-Gm-Message-State: ACgBeo1ovqyM4eQKr96m8z77b0KmqYKPsm60FmNYImdSzEv63QIM+XAt WECtvNpwJGoJxZoaNZMtlN1FGCccgzzAQT6H X-Google-Smtp-Source: AA6agR6CmNb7o28O7pjhCrc+hJxIZ+RXpVVwwfb2fOmOiPJAPeQI1nB6v35XexMi92N3SB9gEIYfqw== X-Received: by 2002:ac8:5a95:0:b0:344:8c79:c6cb with SMTP id c21-20020ac85a95000000b003448c79c6cbmr13766710qtc.14.1661130991417; Sun, 21 Aug 2022 18:16:31 -0700 (PDT) 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 h10-20020a05620a284a00b006b98315c6fbsm9666975qkp.1.2022.08.21.18.16.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Aug 2022 18:16:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------gFGraNv0PlUlKIbhpQ2jf3IS" Message-ID: Date: Sun, 21 Aug 2022 21:16:29 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: Postgresql 14 performance Content-Language: en-US To: pgsql-admin@lists.postgresql.org References: From: Mladen Gogala In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------gFGraNv0PlUlKIbhpQ2jf3IS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/21/22 20:46, Jeff Janes wrote: > > You can see there that little time was spent reading data, so that > explains why repeating the query didn't make it much faster due to > caching.  The time isn't spent reading data, but doing CPU work on > data already in memory. > > Cheers, > > Jeff Agreed. The "perf top" output produced by Kenny definitely indicates that. That's precisely why I concentrated on JIT. Anything else would give us a slim chance of increasing the query speed. Regards -- Mladen Gogala Database Consultant Tel: (347) 321-1217 https://dbwhisperer.wordpress.com --------------gFGraNv0PlUlKIbhpQ2jf3IS Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 8/21/22 20:46, Jeff Janes wrote:

You can see there that little time was spent reading data, so that explains why repeating the query didn't make it much faster due to caching.  The time isn't spent reading data, but doing CPU work on data already in memory.

Cheers,

Jeff

Agreed. The "perf top" output produced by Kenny definitely indicates that. That's precisely why I concentrated on JIT. Anything else would give us a slim chance of increasing the query speed.

Regards

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
--------------gFGraNv0PlUlKIbhpQ2jf3IS--