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 1iiVfB-0001Ip-Eo for pgsql-admin@arkaria.postgresql.org; Sat, 21 Dec 2019 03:42:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iiVf8-00057f-PN for pgsql-admin@arkaria.postgresql.org; Sat, 21 Dec 2019 03:42:42 +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 1iiVf8-00057X-DH for pgsql-admin@lists.postgresql.org; Sat, 21 Dec 2019 03:42:42 +0000 Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iiVf6-0007gn-90 for pgsql-admin@lists.postgresql.org; Sat, 21 Dec 2019 03:42:42 +0000 Received: by mail-ot1-x32d.google.com with SMTP id w21so6680158otj.7 for ; Fri, 20 Dec 2019 19:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=RBugvMXY+WrE1+iRR08Jo4YF06gw3NI8bJKdj7zSKm4=; b=S3fM0W4sdOsBh+QFr43Roq0jDxMoU6iar2nsXQO87E+2Z4rs2u9ZQdw/g/huRNjtJy c9Vctre7I5/Dd+v2tTxwjj311cILINijcPwzefu9sUgJrxwfwmqhjThz6Hyaenh/ihkz v/438pZt49urXYBua6/Ch95ckIUCVf5ydCQf7efXUJZ17uG5YYSAk1+auHPLKzxId6WP 6ZVNLaJ1Ok/3Kg5t/MW3a8XPygR8idy0lk5LM0KXY7UMRS0vL0dWZ2jKitybIBBBb9SB xmSeOCPTezKne6nS7uJ8Xnpq715EoMARlNUv8oMh9mpj/f+ixnOuYGOYb5jGQ92YlbpH EuxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=RBugvMXY+WrE1+iRR08Jo4YF06gw3NI8bJKdj7zSKm4=; b=eh6pjlEeOSV3+ayuKXMq3/cy8IgaU5HMrS54dSdLjLK5oh4HpvcncMNYpMjtuPKV9c MCXe8LTiSgciTGM8tPs3Se9fLsX0//Ol0fuWP63QPrDw95VN0XpdirINN52opBtAluzT 9HttLTh0GLh793STz5D087wqAMqrb+iY88syvtFrkM1fDmVFsTmWJ9q0plfk8oJ2feti xgl9xpGW02EX+rOuqs8LvP+eMyTC6u8iXDxmsJdu+FoqFNJvZCYpdO/QZyrICZTt3hDi 5PZnPhbVfr8YgFKrPj4dm29+KA44Md1o8Zwl3Qhw0C1GhDhryDuf+NVOMU6IQVjbanW0 rrJw== X-Gm-Message-State: APjAAAVTUtSWUZPU9LLW7dmAJnxDWXf74mBdwdWzjYj035WvlyPBlsR8 RYiHEs20dibavCBaeBOXdQyllRsbLdo= X-Google-Smtp-Source: APXvYqy/gz6smmNJHr/+1QyHRq/IzXv+vjm7G8mpyA+nAvnEeimGQrOdQcAWnomRwqCistxVdNMEFQ== X-Received: by 2002:a9d:630d:: with SMTP id q13mr17689788otk.31.1576899757849; Fri, 20 Dec 2019 19:42:37 -0800 (PST) Received: from [192.168.1.10] (ip70-186-126-197.no.no.cox.net. [70.186.126.197]) by smtp.googlemail.com with ESMTPSA id p83sm3894966oia.51.2019.12.20.19.42.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Dec 2019 19:42:37 -0800 (PST) Subject: Re: Partitioning by month causing an error? To: pgsql-admin@lists.postgresql.org References: <9226.1576897186@sss.pgh.pa.us> From: Ron Message-ID: <8ba56626-3b91-6ac8-34a9-ab2c9ca2b8c6@gmail.com> Date: Fri, 20 Dec 2019 21:42:36 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <9226.1576897186@sss.pgh.pa.us> Content-Type: multipart/alternative; boundary="------------AB7050DE567EAD0440184491" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------AB7050DE567EAD0440184491 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/20/19 8:59 PM, Tom Lane wrote: > Wells Oliver writes: >> I have a partition per each month, like this: >> CREATE TABLE mmd_yr2019_3 PARTITION OF mmd FOR VALUES FROM ('2019-03-01') >> TO ('2019-03-31'); >> CREATE TABLE mmd_yr2019_4 PARTITION OF mmd FOR VALUES FROM ('2019-04-01') >> TO ('2019-04-30'); >> This breaks for dates at the end of the month. What's the better way to >> write the bounds? 3/1 to 4/1 and then 4/1 to 5/1? Does that cause some >> overlap issue? > The rule is that a range partition from A to B covers values A <= X < B. > So you should be using first-of-the-month dates for all of these > values. As you have it, there's gaps in the allowable values, > totally aside from the PITA factor of having to identify the last > day of each month accurately. If I were to ask to count *from* 1 *to* 100, you'd count from 1 to 100, *not* 1 to 99.  Who decided to arbitrarily break a grammatical rule we (native English speakers, and I bet everyone else, too) all learn as children, causing all sorts of needless confusion and breakage? -- Angular momentum makes the world go 'round. --------------AB7050DE567EAD0440184491 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 12/20/19 8:59 PM, Tom Lane wrote:
Wells Oliver <wells.oliver@gmail.com> writes:
I have a partition per each month, like this:
CREATE TABLE mmd_yr2019_3 PARTITION OF mmd FOR VALUES FROM ('2019-03-01')
TO ('2019-03-31');
CREATE TABLE mmd_yr2019_4 PARTITION OF mmd FOR VALUES FROM ('2019-04-01')
TO ('2019-04-30');

      
This breaks for dates at the end of the month. What's the better way to
write the bounds? 3/1 to 4/1 and then 4/1 to 5/1? Does that cause some
overlap issue?
The rule is that a range partition from A to B covers values A <= X < B.
So you should be using first-of-the-month dates for all of these
values.  As you have it, there's gaps in the allowable values,
totally aside from the PITA factor of having to identify the last
day of each month accurately.

If I were to ask to count from 1 to 100, you'd count from 1 to 100, not 1 to 99.  Who decided to arbitrarily break a grammatical rule we (native English speakers, and I bet everyone else, too) all learn as children, causing all sorts of needless confusion and breakage?

--
Angular momentum makes the world go 'round.
--------------AB7050DE567EAD0440184491--