Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fXUcR-0002Ug-MI for pgsql-performance@arkaria.postgresql.org; Mon, 25 Jun 2018 16:45:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fXUcP-0001tL-KW for pgsql-performance@arkaria.postgresql.org; Mon, 25 Jun 2018 16:45:33 +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.89) (envelope-from ) id 1fXUcP-0001tA-5j for pgsql-performance@lists.postgresql.org; Mon, 25 Jun 2018 16:45:33 +0000 Received: from mail-it0-x243.google.com ([2607:f8b0:4001:c0b::243]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fXUcH-0004Aj-Gy for pgsql-performance@postgresql.org; Mon, 25 Jun 2018 16:45:31 +0000 Received: by mail-it0-x243.google.com with SMTP id m194-v6so13398069itg.2 for ; Mon, 25 Jun 2018 09:45:25 -0700 (PDT) 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=fDm3f3MMnyOwKRwnrXEcm/DCnvUS6TXckiHofYfAfcQ=; b=lUeYQtTmQb6ccRlvNB1iRGvH8HhnsMmWrLZxa5rrwwhrBgfSYbZ4//An85YlpE60Mr cmthUIh7FoEwZ6eJ0nwIPR/9SC6laSpV9JjsNcZ3B9MirUiAIPTiu6qG3yxVr2OtDeZU 4NHpDZVpVBdwanVkQdltm4P/ZgKiz9F5ixCq4lHMXD49FYe1ex3lAyjwVKbOSq/Bsrmw x7MdGXjpP9frLih9FQyYN4BGKTZ0bEBC+EL/dXZ6naYTZQioZL1PWpAR3Lj3e9qy6Q9K 5P99JFw1s1HY2UhJt5nmE/bJHNIass/tThjgl9zDYRmyTfplIJBzXLkaoKbSkKLeXhWQ qYOg== 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=fDm3f3MMnyOwKRwnrXEcm/DCnvUS6TXckiHofYfAfcQ=; b=oK4QMI57DksFJqOnJumAJ5h6fJgg0qiglfkZA4PY1ke98E8+Cvk5FCBc9sI+kLPBmu 2Snshz1BN/KuFhJoGjegps6YrwolCAajUImQMUQsLu84gK56x4C6R4XLSTD+RG0zR/s8 rxXS4dExA28drCyVW7gKz1uQT82qfwWehV1AujsBRPOpuqIiKPa+P1cDAIZQ6CkPfgTM V3mheqRzf2V8YtbHaW1VoJl9Leaeqo9uVYeSg1G7HegbXd9++r5Ie032VmvIUy7gvUH6 Z8AEVPv/LeFNR12VgFrgYaMasmTxLLzD01Rxqmh7ul9PdBd0PXX4KTLsloGKEEfVlcS/ Z1JQ== X-Gm-Message-State: APt69E271oxFOPNq6bvMT5/T28B0EyNGiGVCP0Zl5aqbWAU59BgtrdnO dQN5ZvCfiT9InocgeuRV9AVeLg== X-Google-Smtp-Source: ADUXVKKoZEdbSFKrWuz6Lxd3EKUJwzS3ukD1SEeAANZSdktRy8j77Q3o5y2K4M3UiIxrYC7GL8jyZg== X-Received: by 2002:a24:5f10:: with SMTP id r16-v6mr1540657itb.73.1529945124265; Mon, 25 Jun 2018 09:45:24 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id t14-v6sm6081804iog.5.2018.06.25.09.45.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 09:45:23 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 9FA3A804E55; Mon, 25 Jun 2018 11:45:22 -0500 (CDT) Date: Mon, 25 Jun 2018 11:45:22 -0500 From: Justin Pryzby To: Roman Kushnir Cc: pgsql-performance@postgresql.org Subject: Re: Slow join Message-ID: <20180625164522.GE20857@telsasoft.com> References: <0B4D190F-CC48-4763-918D-4D4A8DAE5B0B@ad2games.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0B4D190F-CC48-4763-918D-4D4A8DAE5B0B@ad2games.com> User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, Thanks for providing all this info :) On Mon, Jun 25, 2018 at 05:55:49PM +0200, Roman Kushnir wrote: > Hello, > > The following basic inner join is taking too much time for me. (I’m using count(videos.id ) instead of count(*) because my actual query looks different, but I simplified it here to the essence). > I’ve tried following random people's suggestions and adjusting the random_page_cost(decreasing it from 4 to 1.1) without a stable improvement. Any hints on what is wrong here? Thank you. > Running on Amazon RDS, with default 10.1 parameters All default ? https://wiki.postgresql.org/wiki/Server_Configuration It looks like nearly the entire time is spent reading this table: Parallel Seq Scan on videos ... (ACTUAL TIME=0.687..55,555.774...) Buffers: shared hit=7138 read=464357 Perhaps shared_buffers should be at least several times larger, and perhaps up to 4gb to keep the entire table in RAM. You could maybe also benefit from better device readahead (blockdev --setra or lvchange -r or /sys/block/sd?/queue/read_ahead_kb) Also, it looks like there's a row count misestimate, which probably doesn't matter for the query you sent, but maybe affects your larger query: Hash Join (... ROWS=365,328 ... ) (... ROWS=45,307 ... ) If that matters, maybe it'd help to increase statistics on channel_id. Actually, I see both tables have FK into channels.id: > "fk_rails_11d6d9bea2" FOREIGN KEY (channel_id) REFERENCES channels(id) > "fk_rails_257f68ae55" FOREIGN KEY (channel_id) REFERENCES channels(id) I don't see the definition of "channels" (and it looks like the query I put on the wiki doesn't show null_frac), but I think that postgres since 9.6 should be able to infer good join statistics from the existence of the FKs. Maybe that only works if you actually JOIN to the channels table (?). But if anything that's only a 2ndary problem, if at all. Justin