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 1gS5MU-0002Vx-6J for pgsql-performance@arkaria.postgresql.org; Wed, 28 Nov 2018 19:19:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gS5LU-0001qT-PI for pgsql-performance@arkaria.postgresql.org; Wed, 28 Nov 2018 19:18:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gS5LU-0001qM-Dn for pgsql-performance@lists.postgresql.org; Wed, 28 Nov 2018 19:18:00 +0000 Received: from mail-it1-x133.google.com ([2607:f8b0:4864:20::133]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gS5LR-0005yB-8f for pgsql-performance@lists.postgresql.org; Wed, 28 Nov 2018 19:18:00 +0000 Received: by mail-it1-x133.google.com with SMTP id c9so6036441itj.1 for ; Wed, 28 Nov 2018 11:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=ifPa1hQLA2mvo9ahd1oJ1j2JVbnmHLFubi6z/aZEvYc=; b=ItR+PWYX9v2b47PyybbULU+RrHJEIRtNNRkaLt3ZZrtT+HDymgKAmQPbjB2gNWGwVj SCBX30L6OSw4Qu0dwZFc3vHVpftx7eg4duvZJoiOWSIKWRkwBx0gYnQb9k7n5eZnBlC9 3hdf0LE7DQZlB8n94+7lg5o+F1JREA/ED2nMSqCob9AxAJp8Jhv1qXg9mdKJ8E7V5Pa2 mgAyAyczadDjd6WEbYc9tzMpubqPiY8mb2ewRL6V4rQdD2VtuGXsxLW11EtqD8XoLxVe zf03WUfWIbwPuwWyRY4hEitUF19mWhfuWj4vkpVeddAnSvqB0v+lEYhFyI0u8xmYg0A2 fIoQ== 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:content-transfer-encoding :in-reply-to:user-agent; bh=ifPa1hQLA2mvo9ahd1oJ1j2JVbnmHLFubi6z/aZEvYc=; b=N5ICeLt/cXnIq9J5SHKC2H76pt1sZ3FynAvLuevjeiQOK+7LrTgkmMty1MZiXwypPW ffwVMoyq2sj0Mt1Ras7/Wa6YaKvtqYJFg9SJssuAtmMKJB7XJS9yWQ7i+nN3CDCt9eYm 84vK32waHsuBW2prY8qhqqTheSiQ/fgiN0hkCvuHWuhOj//bOW7bchzw1f45VigGbbW4 oW8JCXjh6UsFZftJrvuGvuDEqSb5mL/K9nyuTdrj3V4LJYn5c6hdC0YabQ+mroLWSwDQ /qJ4zbgIuZeRygn8iG3BwZA+J76wP/EwMdKyO2J3xbsPKH+uEcOSZ5C/PZ2RUVEfHlIu MScg== X-Gm-Message-State: AA+aEWarVbGv0tVhj3Wcpf/BtbaUtVZOfYkCd9792TecdD7veIt4atQk BVF0YGl0M6al8c87KtWKOTraxfVKjno= X-Google-Smtp-Source: AFSGD/VXKnfpsAsVwJsUnWP2HuZlM+SiotyXm/H4nms7ZcrmnOxVtw3N0dDK3sTePKvce4Utat2UZw== X-Received: by 2002:a24:4e0d:: with SMTP id r13mr3943937ita.140.1543432675235; Wed, 28 Nov 2018 11:17:55 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id b5sm2981706ioc.21.2018.11.28.11.17.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 11:17:54 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 68C54804CB3; Wed, 28 Nov 2018 13:17:53 -0600 (CST) Date: Wed, 28 Nov 2018 13:17:53 -0600 From: Justin Pryzby To: Scott Rankin Cc: "pgsql-performance@lists.postgresql.org" , Eric Meaney Subject: Re: Slow Bitmap Index Scan Message-ID: <20181128191753.GM30707@telsasoft.com> References: <05111C93-69B4-4D5B-8AD3-8C9C47E0F01E@motus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <05111C93-69B4-4D5B-8AD3-8C9C47E0F01E@motus.com> User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Nov 28, 2018 at 07:08:53PM +0000, Scott Rankin wrote: > We recently moved our production database systems from a 9.4 running on a self-managed EC2 instance to 9.6.10 on Amazon’s AWS (same RAM, CPU). After the move, we’re finding that certain queries that we run against a GIN full-text index have some occasionally very slow executions and I’m struggling to figure out what to do about it. I would be very grateful for any ideas! > > The setup we have is a 32-core, 244 GB RAM primary with a same-sized read replica. The queries are running off the replica, but performance is roughly the same between the master and the replica. > > Here’s a query that’s performing badly: Can you compare or show the explain(analyze,buffers) for a fast query instance vs slow query instance ? Is it slower due to index access or heap? Due to cache misses ? Also, you have big ram - have you tried disabling KSM or THP ? https://www.postgresql.org/message-id/20170718180152.GE17566%40telsasoft.com Justin