Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPBZ8-0004Yf-53 for pgsql-performance@arkaria.postgresql.org; Thu, 05 Jan 2017 17:11:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cPBZ7-0001xn-OW for pgsql-performance@arkaria.postgresql.org; Thu, 05 Jan 2017 17:11:01 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cPBZ6-0001xb-T0 for pgsql-performance@postgresql.org; Thu, 05 Jan 2017 17:11:01 +0000 Received: from mail-oi0-x22c.google.com ([2607:f8b0:4003:c06::22c]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cPBZ3-0000Ot-Ua for pgsql-performance@postgresql.org; Thu, 05 Jan 2017 17:10:59 +0000 Received: by mail-oi0-x22c.google.com with SMTP id b126so587370501oia.2 for ; Thu, 05 Jan 2017 09:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=l9KEYLwhfl8/49BaRbrH6XhCwtlMu5YyiSu8yJjGIU4=; b=qnTPTjrCQby8bdDUC1sCH7Ytb876mBSyoHN5k/bxId1ir2sGevPuq1azATldvRIdYn ZYx5x+cNT1Fa9TKlvqzaotHdnORr33GYJ8I/i62k52yF5CRvxkESOdzsV/ySsZFKx4sb fwj75lyNCBBv+cmdrEymo9MBZco1UghX0B/le0kWxEv2rdeVaJKyjwN6bkzct4XD8S8H lLGM0BVv80Vt7nDTNfWFtYDHBnlirKRlFnBkT6kv+H7+GrMLlulfWvPCSo5O+1N4WPy6 iA37P0NCdH8lLt3h/tnkRss77zVBRvmvqRU1qKmeMmoZ5meVjW5Y9rQO4YUYryM38mWm Z+Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=l9KEYLwhfl8/49BaRbrH6XhCwtlMu5YyiSu8yJjGIU4=; b=Xye6oEJS+GpW1bCFBNs53NCvSFOLIJJouqIU3OOTynrjY2D79CO2ktK7svia4ZHWTg Sm+xZg20ZxIyuvUn6kAfXIPJDjCFAzjLYrAGqX/SdqZB351pDPaGd+/kKkumg9gXkHzG S7hUOg0gvh3CMoVwYNg88c//xbSALSHQbGY92NWJXp31WMeAUgbzRQzoCGFCXP3hHoiw GRdGwXDre11TkJB8e4ZZ3ZM+y7L0DHd35fpO6f9/QkOcAK+V4p7L2Jr665ZJeemsGXkJ CBsJmwQWAgnbFSfaaU3zTUW/E7le5vxGvHSVOVoJcMVMSarHFOdwcegg6sLWEB0GqFPY SBNQ== X-Gm-Message-State: AIkVDXLDYWkTgITL0re0uy90V2xu+j/poD7e+NJH/Oyz3pKumElggavPgXc/jCBoWbkKxFoz7izs5+lyF+16yQ== X-Received: by 10.202.81.66 with SMTP id f63mr3507911oib.184.1483636257460; Thu, 05 Jan 2017 09:10:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.193.71 with HTTP; Thu, 5 Jan 2017 09:10:57 -0800 (PST) In-Reply-To: References: From: Kevin Grittner Date: Thu, 5 Jan 2017 11:10:57 -0600 Message-ID: Subject: Re: Slow query after 9.3 to 9.6 migration To: =?UTF-8?Q?Fl=C3=A1vio_Henrique?= Cc: Merlin Moncure , postgres performance list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On Thu, Jan 5, 2017 at 10:51 AM, Fl=C3=A1vio Henrique = wrote: > Replying your comment, I think they tunned the server: > effective_cache_size =3D 196GB > shared_buffers =3D 24GB (this shouldn't be higher?) Probably not, although it may be a good idea to try settings either side of that (say, 16GB and 32GB) and monitor performance compared to the current setting. > autovacuum_max_workers |3 If you ever see all workers busy at the same time for 30 minutes or more, you should probably consider raising that so that small, frequently updated tables are not neglected for too long. > autovacuum_vacuum_cost_limit |-1 That is going to default to vacuum_cost_limit, which is usually 200. If the server is actually big enough to merit "effective_cache_size =3D 196GB" then you should probably bump this setting to something like 2000. > autovacuum_work_mem |-1 That is going to default to maintenance_work_mem. On a big machine, you probably want that set to somewhere between 1GB and 2GB. Some other tuning to the cost parameters might be helpful, but there's not enough data on the thread to know what else to suggest. If you hit some other slow query, you might want to report it in the manner suggested here: https://wiki.postgresql.org/wiki/SlowQueryQuestions -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company --=20 Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance