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 1eiMAq-0006Uk-R0 for pgsql-performance@arkaria.postgresql.org; Sun, 04 Feb 2018 15:25:45 +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 1eiMAp-0005tc-CK for pgsql-performance@arkaria.postgresql.org; Sun, 04 Feb 2018 15:25:43 +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 1eiMAo-0005tQ-TL for pgsql-performance@lists.postgresql.org; Sun, 04 Feb 2018 15:25:43 +0000 Received: from mail-io0-x243.google.com ([2607:f8b0:4001:c06::243]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eiMAg-0001fx-VY for pgsql-performance@lists.postgresql.org; Sun, 04 Feb 2018 15:25:41 +0000 Received: by mail-io0-x243.google.com with SMTP id t22so27739872ioa.7 for ; Sun, 04 Feb 2018 07:25:34 -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=OGoDJEztni81ZlLH+hdQrgDcLXIjig6A6wc7ER5gyo4=; b=waAN8u1dMODAO1yW6jLeIUtx20jflSlbrd77xquPgf8tghBZ3+hl7V+44fV/AsyLmX 5Zkg2O4BaPOz3cg3f6Uxofl83xsWWBtDISzgLvM6L9rfVFnFM/dFWFQ2sdF3XVGYqA6F EqZGbU35b4AyMUqYGOxMXDKw1Xm487CbZp7alW6Zu7cmKNXR+yE+G+tsoWjBXp+Tfmvg jlqdPvv/3NgPENBd+3lZLXyE04c7zgxhpMZW3GZFZaFVovy8cD+cQ8cRoESaM+pe8iWm lb9r6tdHmy4ztQzT6zoTU6uMtYRA9C4OIu4aDmVNzeGomi2VSamRIWsubZaYiaWcuuZo INoA== 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=OGoDJEztni81ZlLH+hdQrgDcLXIjig6A6wc7ER5gyo4=; b=gEBqFC5pAf+f+BkPFgRp4nZUozdMOT2ervCQyqah0RmPIcKqNmIwbnOw+x6JiTLnNp iz6NTZ22vaGCZqV6sEyN5Q80/39NR55vqwkb0ED4Semtf6toNo9tMsuvo079G1wU+J7x sEwSk/MH6cto59OU05/A1de27hahwrmpZNzt8RYm7bx+LnFW1sUHMjz85gFH4OC5i1th +20dzJorfZfugg+JnflWat5zTqotc/jUhKTAjcs93MJtH94R4dW7a0rQTT+BZ0Dbc6wI mmDLcQF9y1yhNGhj3bdUCZAsW5oR7OlcHW2XiXARdF/i/wK3D422H4NrPh05bt+SIqhE 8sUA== X-Gm-Message-State: AKwxytfTnxBiCf1SmUZ2rS9jqKTmDkvHRrZItJl+N/uzYQ27iQf2CL4+ bLLte3h3b8M+oKx2xYxQdtQLMw== X-Google-Smtp-Source: AH8x225ogwHzmq73FCo6uXg656nWM1MxW41xEfQFaldTePLSSIedygV5IIJqgfU7MKJqEZ3F8ekwng== X-Received: by 10.107.155.212 with SMTP id d203mr38246734ioe.247.1517757933261; Sun, 04 Feb 2018 07:25:33 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id s8sm3907569itb.39.2018.02.04.07.25.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Feb 2018 07:25:32 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 2CB3880100E; Sun, 4 Feb 2018 09:25:32 -0600 (CST) Date: Sun, 4 Feb 2018 09:25:32 -0600 From: Justin Pryzby To: Mariel Cherkassky Cc: Andreas Kretschmer , pgsql-performance@lists.postgresql.org Subject: Re: postgresql 10.1 wrong plan in when using partitions bug Message-ID: <20180204152532.GT26916@telsasoft.com> References: 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 05:06:38PM +0200, Mariel Cherkassky wrote: > Great, it solved the issue. Seems problematic that the planner do full > scans on all partitions in the first case isnt it ? Seems like a bug ? See also: https://www.postgresql.org/message-id/20170725131650.GA30519%40telsasoft.com https://www.postgresql.org/message-id/20170825154434.GC16287%40telsasoft.com Justin 2018-02-04 16:54 GMT+02:00 Andreas Kretschmer : > > > > > Am 04.02.2018 um 13:19 schrieb Mariel Cherkassky: > > > >> I checked the plan of the next query : > >> explain select count(*) from log_full where end_date between > >> to_date('2017/12/03','YY/MM/DD') and to_date('2017/12/03','YY/MM/DD'); > >> > >> > > can you rewrite the query to > > > > ... where end_date between '2017/12/03' and '2017/12/03' > > > > maybe the planner should be smart enough to do that for you, but obvously > > he can't. So it's a workaround, but it seems to solve the problem.