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 1mJWNG-0005Uo-Fl for pgsql-general@arkaria.postgresql.org; Fri, 27 Aug 2021 07:34:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mJWNF-0000g8-7P for pgsql-general@arkaria.postgresql.org; Fri, 27 Aug 2021 07:34:01 +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 1mJWNE-0000fz-VG for pgsql-general@lists.postgresql.org; Fri, 27 Aug 2021 07:34:00 +0000 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mJWN8-0006Qo-3v for pgsql-general@lists.postgresql.org; Fri, 27 Aug 2021 07:33:59 +0000 Received: by mail-wr1-x42c.google.com with SMTP id i6so8987985wrv.2 for ; Fri, 27 Aug 2021 00:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=Rn/PMds1KUaJx/edLmvta+YVSUN7O8z2OEYi1riz9PM=; b=OM6jJUQ8OehCCBfcHYZ6wMSTqwNj12whghiozMFNlZ8pdbHF3WwhSB6xzapjZ5QAip 36MtulIPXURcYw/96+NLdUdaV2JVMO9TScK3ZcH+ou07FzvYpHq+CGFXzU5pWEYx8ysI GtUy4mzFKBovoJ5OaPkAYtAkqSoz3ebw/7bvERS5jO1axzlQa/ymMVVHn3kSI3lV5ctf JfWWnH3DXrdg6/6uyRPQR65c7EwAh+BMLyBBUdQwOajgoE+WCBbhbVSRAjZPmNzrvTZQ j20JHUabPMMV6WpwC9BXET6iyoahllgcQI52b6FrKehsW7QHEFABLIYm7QipESltAFrS CPMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=Rn/PMds1KUaJx/edLmvta+YVSUN7O8z2OEYi1riz9PM=; b=m3NYNNF2AuOEblEYYLs2ZnHUREmxNDLg6d1bnT42+xDfWFIRllKJ4edNbOnu4QgP3e 7yx3TlGzw7OKKoTOl+KrCci3AMmmn/IobSMxjr5JpJZ+zCh75thFSrR4AQcqmoSz0ovo 6lvsI4UWeKKyVRHQSKWOVMI5bo/tynSUiwT/N2sbMP8l7z5W1PRbhWPh6AhGfUGmGxe1 Y3NCY4ba9W5P3dHtu1vECRozObB4vwiD9s92J799rDwi/ef8lvEruDHbNiJIzgQwWeXV v1Sx1EAj41LwiObQVUK3rB3Bn7GoNuwtEL3k5r98wxRLNa/v+aS7kgPicA+OA9vZDfDk Z+3Q== X-Gm-Message-State: AOAM531jG5gYDNtwGOD2NAUba4tupafG6IJqf6voQcmptTOKIzADQ3kq 5Ejtt0JMW9cmgCbe7meLWyOu7A== X-Google-Smtp-Source: ABdhPJxKA4VFWIyCdL+P2fQlABr7NoiAIdbFqrNZk9AA88bKb2wQ2VZCFkskRSd0iS0unGf3gb0X1w== X-Received: by 2002:adf:e910:: with SMTP id f16mr8551007wrm.393.1630049632505; Fri, 27 Aug 2021 00:33:52 -0700 (PDT) Received: from localhost.localdomain (dynamic-e41ynjkw44ykta3or-pd01.res.v6.highway.a1.net. [2001:871:5c:e82d:7c71:3f6d:7e60:5e2b]) by smtp.gmail.com with ESMTPSA id b15sm6141902wru.1.2021.08.27.00.33.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Aug 2021 00:33:52 -0700 (PDT) Message-ID: Subject: Re: Can we get rid of repeated queries from pg_dump? From: Laurenz Albe To: depesz@depesz.com, Tom Lane Cc: pgsql-general Date: Fri, 27 Aug 2021 09:33:51 +0200 In-Reply-To: <20210826160644.GA3120@depesz.com> References: <20210826084430.GA26282@depesz.com> <648517.1629986527@sss.pgh.pa.us> <20210826140827.GA15868@depesz.com> <649446.1629987629@sss.pgh.pa.us> <20210826160644.GA3120@depesz.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 2021-08-26 at 18:06 +0200, hubert depesz lubaczewski wrote: > Now for query stats. > > To dump it all, pg_dump needed 9173 queries (logged by > log_min_duration_statement = 0 for this user). > > I extracted all queries to separate files, and made stats. In total there were > only 4257 unique queries. > > Then I checked for repeated queries. Top 10 most repeated offenders were: > > 615 times : SELECT pg_catalog.format_type('25'::pg_catalog.oid, NULL) > 599 times : SELECT pg_catalog.format_type('23'::pg_catalog.oid, NULL) > 579 times : SELECT pg_catalog.format_type('2281'::pg_catalog.oid, NULL) > 578 times : SELECT pg_catalog.format_type('41946'::pg_catalog.oid, NULL) > 523 times : SELECT pg_catalog.format_type('701'::pg_catalog.oid, NULL) > 459 times : SELECT pg_catalog.format_type('42923'::pg_catalog.oid, NULL) > 258 times : SELECT pg_catalog.format_type('16'::pg_catalog.oid, NULL) > 176 times : SELECT pg_catalog.format_type('19'::pg_catalog.oid, NULL) > 110 times : SELECT pg_catalog.format_type('21'::pg_catalog.oid, NULL) > 106 times : SELECT pg_catalog.format_type('42604'::pg_catalog.oid, NULL) > > In total, there were 5000 queries: > SELECT pg_catalog.format_type('[0-9]+'::pg_catalog.oid, NULL) > > But there were only 83 separate oids that were scanned. That is a strong argument for using a hash table to cache the types. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com