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 1eimIh-0000hI-CS for pgsql-performance@arkaria.postgresql.org; Mon, 05 Feb 2018 19:19:35 +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 1eimIg-0004n1-GZ for pgsql-performance@arkaria.postgresql.org; Mon, 05 Feb 2018 19:19:34 +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 1eimIg-0004ms-4I for pgsql-performance@lists.postgresql.org; Mon, 05 Feb 2018 19:19:34 +0000 Received: from mail-it0-x243.google.com ([2607:f8b0:4001:c0b::243]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eimIX-0004Cq-Uw for pgsql-performance@lists.postgresql.org; Mon, 05 Feb 2018 19:19:33 +0000 Received: by mail-it0-x243.google.com with SMTP id u12-v6so9728943ite.0 for ; Mon, 05 Feb 2018 11:19:25 -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=dyHZ/ngeo8VuGanZkVJ4fGJBSwlTguY8ZNXNBXAhLCw=; b=bca2E4b01w4j0MTx53Ku6LcSolU9i9OKUtb7D0Pb5euDn7AOJ2cg7UaZ76ccbJOzyH A4Elr/oY1UoCDdnADfB002KA3HszSqm0QdARLmnHEGYRQPPWsrEscMwQeOanN37fznTm kq0jFJZWfHTU5kRQo8uOfCGkGoOqLcM0LMEC/ET72Osh+LKj5a78YnaNNQIuifIs8DBu tYoWKkFOsqrq2k2V4J9oRHVwSlUukYWuLU0zegVlIuXVfhpcCUGLoStQdPHIWoDkBWP0 mhVN3bgdUtvGQ0q/UeYV7Su9iAkYzK3Q80NPw3LGg4nRtcBGu/r41qbzKWVSBOIaKJb/ ekrg== 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=dyHZ/ngeo8VuGanZkVJ4fGJBSwlTguY8ZNXNBXAhLCw=; b=VtcVo456UDvAtX+ptuCOY3o2vQ2X7uwQtkzI9mJhImj5sx737Fn3Q1BGVzhxjgfBkl 0CeCo/8WVQ+vTErjWlS7OfV5A2p+WB/STkLWeEF2VDCeASfmghs0aj6t9VqFZHLrqNnA +xAGbE7WGJ74i0+5jinawfjv11PYm9SyDYy7QoS5gWMVv2TvB4eVPHTmHjULvjoEsC14 GGhDXOCIR12DFD48+Ema7+dHFFLMYUvvq632P1i/0w6PJaSuP3T/Dii8Ug5KiHz2y8Jg xKvk138UrIGsyTfIFi9dhMIIcwhqOQXfNwhKGrdF1fUqkykLf/8a4B+YZsIqnPDR2fAI G6sw== X-Gm-Message-State: APf1xPAAq/1SCogs5grFMkHC4YAnHvm8oTMpRN2G1W40D0NMb56NQxoI F6t8Mj9wDDKfMfLMuc+uxwVqGw== X-Google-Smtp-Source: AH8x225JYn0GTWOal7OJYuggfnChREOmT37HjZUWaDmFkjz53V+4jcYkzD8sRIaJdWyhpb9gS3M0vw== X-Received: by 10.36.55.78 with SMTP id r75mr542676itr.109.1517858364201; Mon, 05 Feb 2018 11:19:24 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id m100sm5651012iod.52.2018.02.05.11.19.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 11:19:23 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id A370880100E; Mon, 5 Feb 2018 13:19:22 -0600 (CST) Date: Mon, 5 Feb 2018 13:19:22 -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: <20180205191922.GN32634@telsasoft.com> References: <20180204152532.GT26916@telsasoft.com> 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:28:52PM +0200, Mariel Cherkassky wrote: > I read those two links and I dont think that they are relevant because : 1 > 1)I didnt do any join. > 2)I used a where clause in my select https://www.postgresql.org/docs/current/static/ddl-partitioning.html |The following caveats apply to constraint exclusion: | Constraint exclusion only works when the query's WHERE clause contains |constants (or externally supplied parameters). For example, a comparison |against a non-immutable function such as CURRENT_TIMESTAMP cannot be optimized, |since the planner cannot know which partition the function value might fall |into at run time. [..] The issue is with the comparison between function call to to_date() compared with constant - that doesn't allow constraint exclusion as currently implemented. 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.