Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ej7oy-00031Y-C6 for pgsql-performance@arkaria.postgresql.org; Tue, 06 Feb 2018 18:18:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ej7ox-0004EJ-3M for pgsql-performance@arkaria.postgresql.org; Tue, 06 Feb 2018 18:18:19 +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_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ej7ow-0004E9-OE for pgsql-performance@lists.postgresql.org; Tue, 06 Feb 2018 18:18:18 +0000 Received: from mail-it0-x22a.google.com ([2607:f8b0:4001:c0b::22a]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ej7op-0000SY-FJ for pgsql-performance@postgresql.org; Tue, 06 Feb 2018 18:18:18 +0000 Received: by mail-it0-x22a.google.com with SMTP id 196so3500568iti.5 for ; Tue, 06 Feb 2018 10:18:10 -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:in-reply-to:user-agent; bh=Y4KbZtM7IA8B1q0gk9zRUWutAovKZ8h74QbB4pfvaYw=; b=DhbHxzeMrIYLDHEtj0ZGbaLT52GVX/diEYJTkBHcMbvgZZ+cU8DEybaEBeutk2vHW/ l2g+97fDpObo/nAsj1ACIGEpp6vqZ7galyxHJ6Rwte51h1SDQLwLwUTNgOqHPysA30h8 4s44QqNSF1PeF1apkP2Doi9BPjrUNw9RYiLe7WevV0lw4spsJtTATZ4Js9pCL955+VHd +Bt+hLUlqRhnkzUtd9X8LquGeh5App9jTccxDjpM8vwISe7sUQshCRaigvH/pOvoc+s1 xqc+4uCcEDgWh9iY7LxSmh9uCJ8Ogu/djLZNzWzdcaOxaPSqoHcLkHhMBAAJ8lsY6YEO EF0w== 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=Y4KbZtM7IA8B1q0gk9zRUWutAovKZ8h74QbB4pfvaYw=; b=L6+CyJ+hieePqbYPiZBkVHorc0QrvyxWC/IJ3HGczYOMK9AFpRH9PBD5uNPuaDx9Sq dGfWtaHlstHUP9kCUN7mUdVPX8Du/iNLYGRgVaBS3JEePJQJn/VVpaE21AfTlb6wHhvt aqvzfPKCALn+iyR2MixVjaDWQ2Yalcu5xo4KZbj3q/khqLNucV672IBEGzueRj8X4fwi Ab/qiNo1DVyZbgtuYGjDbi4Bv9g2BPBudN7hMNwCJk47hbA6KabeVBakISQw5dpuEOxG caqlz5hGJPBdicFrXksjzvBbTP/C0McDu6yY6P7YU5n6u3skbkAbUR736m/R3SiQD6fg qtog== X-Gm-Message-State: APf1xPC1x1HCZVAdl3X4fKKtKAhiFHRf+mFimhzYcHI6Yi2C0b9A+lbP D5830KNordm2+GQEmLJ62f6ojQ== X-Google-Smtp-Source: AH8x227EGdcAx7V0jth0eFzamFMKWrwL+HHGgBFa9SdNmV5bEa4/G5s6nIXbMMcSzFpHX+tueWawcA== X-Received: by 10.36.26.137 with SMTP id 131mr4189165iti.25.1517941089122; Tue, 06 Feb 2018 10:18:09 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id c9sm7542709iod.5.2018.02.06.10.18.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 10:18:08 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 8890A80100E; Tue, 6 Feb 2018 12:18:07 -0600 (CST) Date: Tue, 6 Feb 2018 12:18:07 -0600 From: Justin Pryzby To: Rick Otten Cc: Tom Lane , PostgreSQL mailing lists Subject: Re: failing to use index on UNION of matviews (Re: postgresql 10.1 wrong plan in when using partitions bug) Message-ID: <20180206181807.GC32634@telsasoft.com> References: <15450.1517758532@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Feb 04, 2018 at 11:04:56AM -0500, Rick Otten wrote: > On Sun, Feb 4, 2018 at 10:35 AM, Tom Lane wrote: > > > Rick Otten writes: > > > I'm wrestling with a very similar problem too - except instead of > > official > > > partitions I have a views on top of a bunch (50+) of unioned materialized > > > views, each "partition" with 10M - 100M rows. On 9.6.6 the queries would > > > use the indexes on each materialized view. On 10.1, every materialized > > > view is sequence scanned. I think it'd be useful to see the plan from explain analyze, on both the "parent" view and a child, with and without SET enable_seqscan=off, Justin