Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hTTMh-0007qS-UK for pgsql-performance@arkaria.postgresql.org; Wed, 22 May 2019 15:41:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hTTMe-0002Lf-HH for pgsql-performance@arkaria.postgresql.org; Wed, 22 May 2019 15:41:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hTTMd-0002LX-Sw for pgsql-performance@lists.postgresql.org; Wed, 22 May 2019 15:41:12 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hTTMa-0000wZ-C7 for pgsql-performance@lists.postgresql.org; Wed, 22 May 2019 15:41:10 +0000 Received: by mail-wr1-x444.google.com with SMTP id g12so2830061wro.8 for ; Wed, 22 May 2019 08:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=4ytl0K3IjMv2Qn6Xs8WAvFboZpo74etbB8GzXFt6Wq4=; b=zRb0qTVZIha/Ybw62Ug6xbBosKoCWVfOZeDNDN2HQLwE04pLjtPI6RalyLy5ryYT0w +quvPjwHnqP/XkCxMzfJ5FuBmBh2UkmQYqOJ01CI8buTVl83lwZLdtgbHVJsfrqemNA7 0XGrCNRjdlGpd8HD4iF3RBRI4bNnPU83FI25H1fN1CoPHAVa9bMJBUSbAsORXIpRwlH3 Yv0HNoS7lC8QSNlNHOmMXRLQugCfIyADvcjYv/zKpYZIqZ0OAypBpbqg0xfywd71LOAy 6mnLkOYW1SGrc6DtnOo3GLU0lZETP7m1ERPqtoOF8ujzSto/ef/+BF8BvUbuvwyDV7zE oLgw== 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:user-agent; bh=4ytl0K3IjMv2Qn6Xs8WAvFboZpo74etbB8GzXFt6Wq4=; b=J926VzZq6xLbmeIXlOkvnACxgXibF1zJlLjV/svnv7qpsqLD9WCrE03MgPD9Fk/Jv4 oc0xUpz3UQGkutKNS+AauT2nDF1l/a9rdmO7KY0JQtrpqwZ+6S6fqVgrNIjEdNi/3RfZ qICbeOno+Y/oH7RybkDNRkJKmNPj3TnI006SJKyK7CG2u+ph5z6Mxd8zM4jkb2ATaXaY fGEoSblbBDc78JFZdxzJQRD69T9TbWWW/IlY/gual6/tLUHoG6j1dAz/zrlGQCsyKW06 i1kAWOnW2LeRZGLQiyHUS+a3PpwXA+AMEYYCz24YCRC4tTh4BZ3SYROKSVMs2gksVMZj zNWw== X-Gm-Message-State: APjAAAXPidZaApXqQlvmVPm4kFrHgE1jYNUV3UKBhZm/t0pnKUWnN134 dxGICT4fxgmlRE0s0PepwApThA== X-Google-Smtp-Source: APXvYqwrPavyPILyAAaNRHObAWGZot4f3yVVORhCzrFUxW0aJkNb/Wros/gRXrNWN6uzMQ8/rAAqjg== X-Received: by 2002:a5d:4e50:: with SMTP id r16mr17205299wrt.197.1558539665123; Wed, 22 May 2019 08:41:05 -0700 (PDT) Received: from localhost (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id q15sm8348566wrr.19.2019.05.22.08.41.03 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 22 May 2019 08:41:04 -0700 (PDT) Date: Wed, 22 May 2019 17:41:02 +0200 From: Tomas Vondra To: Mariel Cherkassky Cc: pgsql-performance@lists.postgresql.org, pgsql-admin@lists.postgresql.org Subject: Re: pg_restore takes more time on creation of rules Message-ID: <20190522154102.zpvieebklnvis5u3@development> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716-1444-295967-dirty List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, May 22, 2019 at 06:26:49PM +0300, Mariel Cherkassky wrote: >Hey, >I'm trying to restore a cluster (9.2) from 3 binary dumps (pg_dump -Fc). >Each dump contains only one database. >The sizes : >A-10GB >B-20GB >C-5GB. > >For unclear reason the restore of the third database is taking alot of >time. It isnt stuck but it continues creating db rules. This database has >more then 400K rules. > What do you mean by "rules"? >I changed a few postgresql.conf parameters : >shared_buffers = 2GB >effective_cache_size = 65GB >checkpoint_segments =20 >checkpoint_completion_target = 0.9 >maintenance_work_mem = 10GB >checkpoint_timeout=30min >work_mem=64MB >autovacuum = off >full_page_writes=off >wal_buffers=50MB > >my machine has 31 cpu and 130GB of ram. > >Any idea why the restore of the two dbs takes about 15 minutes while the >third db which is the smallest takes more than 1 hour ? I restore the >dump with pg_restore with 5 jobs (-j). > Well, presumably the third database has complexity in other places, possibly spending a lot of time on CPU, while the other databases don't have such issue. What would help is a CPU profile, e.g. from perf. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services