Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dapkJ-0001E1-Cs for pgsql-performance@arkaria.postgresql.org; Thu, 27 Jul 2017 20:50:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dapkI-0001Sp-Oz for pgsql-performance@arkaria.postgresql.org; Thu, 27 Jul 2017 20:50:58 +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 1dapiX-0006iH-76 for pgsql-performance@postgresql.org; Thu, 27 Jul 2017 20:49:09 +0000 Received: from mail-qt0-x235.google.com ([2607:f8b0:400d:c0d::235]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dapiQ-0008Pr-5v for pgsql-performance@postgresql.org; Thu, 27 Jul 2017 20:49:07 +0000 Received: by mail-qt0-x235.google.com with SMTP id p3so67668492qtg.2 for ; Thu, 27 Jul 2017 13:49:01 -0700 (PDT) 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=WdN+JGJ8esuj2H9kkb/yLodXC9DiBhBUtwlIMRtNL1k=; b=UMDCFj+USXV3rNxESTVESh1ZmyBy61JrkQWaTIqcuVhik3/qG+UK9wo+3g+McLnydU Jt7fuiSuzxXEhHeb6YYwkUqKkbAVGWHExKregrUA7iBd9wQFlMUNGHXgEauO1Xs3gb8U Uk04DIKIZ3LPGanPIDJmHKloHcw/hmOYfqMhwb2K1l1/xsv5EVM2+rq2Y7vm3ELkXIQa yLNhn5szfuajMDL7598qgByS+txLOi7pXgtCiu2PpevDj9cxmEZa3iDL8KBY9bBEBxaj fa3PD8wPlJs/DJs0ZIz93UgGM6CGzNcuhTmQW6Nlx3TAEbBM5Y+CHR2og6LnEqsGNJTH I4pQ== 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=WdN+JGJ8esuj2H9kkb/yLodXC9DiBhBUtwlIMRtNL1k=; b=WsZ+lq0cfw7sgkkn20yWWBShICrpFGNv96J/209jipPD4keiv6CpHCGVwVR0fq0LkN KJVBe+UKIPzH9lKKfSuXxQ8olUZfSG/GYBppbHaKe56MKIBaN6VP5LxRSrXZZQ3xCG25 I0U+nxtXaDZU9ylT6SYv8XrQB0m3BnSuJtuIujnMv+LCaenytawmKp+EwFQlD3mBbYNf iHu4EFikepbhXb31l+PPKE/eTEeBG421P6tdSXlRffZX2SZf550IZta3ctgZmz6TDCZ0 AtAFdM3rTYudx3RIwCZB4f3BuKXtB9+6BVkDvlj8TVJTSEcQiRMBZSgvJ8BXNWibKBuo J8Sw== X-Gm-Message-State: AIVw110NpsFZ4yIO1cVZ5R1MuATG8+5ytkbiPHZ8PDzGWtj+mpKgxqAW 8dgc9YvE0T4aB97RLES8TktVDTKFaw== X-Received: by 10.200.37.206 with SMTP id f14mr7202484qtf.271.1501188541072; Thu, 27 Jul 2017 13:49:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.17.85 with HTTP; Thu, 27 Jul 2017 13:49:00 -0700 (PDT) In-Reply-To: References: From: Scott Marlowe Date: Thu, 27 Jul 2017 13:49:00 -0700 Message-ID: Subject: Re: Slow query after 9.3 to 9.6 migration To: =?UTF-8?Q?Fl=C3=A1vio_Henrique?= Cc: "pgsql-performance@postgresql.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Tue, Dec 27, 2016 at 3:50 PM, Fl=C3=A1vio Henrique = wrote: > Hi there, fellow experts! > > I need an advice with query that became slower after 9.3 to 9.6 migration. > > First of all, I'm from the dev team. > > Before migration, we (programmers) made some modifications on query bring > it's average time from 8s to 2-3s. > > As this query is the most executed on our system (it builds the user panel > to work), every bit that we can squeeze from it will be nice. > > Now, after server migration to 9.6 we're experiencing bad times with this > query again. > > Unfortunately, I don't have the old query plain (9.3 version) to show you, > but in the actual version (9.6) I can see some buffers written that tells= me > that something is wrong. > > Our server has 250GB of memory available, but the database team says that > they can't do nothing to make this query better. I'm not sure, as some > buffers are written on disk. The second sorts etc start spilling to disk your performance is gonna tank. Try increasing work_mem to something moderate like 256M to 1G. Note that work_mem is per sort / action, so if you got 100 users running queries with 2 or 3 sorts at a time you can exhaust memory real fast. OTOH, a db with proper pooling on connections etc (aka 10 to 20 live connections at a time) cna easily handle 1G work_mem if it's got 256G RAM --=20 Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance