Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aYy6U-0006IG-Ot for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Feb 2016 15:45:23 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aYy6U-0005O3-4b for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Feb 2016 15:45:22 +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) (envelope-from ) id 1aYy58-0003p4-NH for pgsql-hackers@postgresql.org; Thu, 25 Feb 2016 15:43:58 +0000 Received: from mail-lf0-x235.google.com ([2a00:1450:4010:c07::235]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aYy55-0001Ih-TD for pgsql-hackers@postgresql.org; Thu, 25 Feb 2016 15:43:57 +0000 Received: by mail-lf0-x235.google.com with SMTP id m1so35822819lfg.0 for ; Thu, 25 Feb 2016 07:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-djuster.ca; s=google; h=reply-to:from:mime-version:thread-index:date:message-id:subject:to :content-type; bh=ya7eL1dn8ATDY2GQ2l4q9OhaUtxb8s5SOPpC/IcmznY=; b=Vj8+IFNf3h02zDt9ChGAThdTLpGN+TyaNszKNUjF+RH5L0YJfkau+LQSyGuVZnkIBw GA1TxGsp+pZ04KZ04ITf9euEovS/n27Lo6hvLLJwf+nHHoMYLc6hnNizziCHPwSNCb3Z qVWiJ7jvbXL//Z6XuIru7DamY3Ls6223/XnKU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:from:mime-version:thread-index:date :message-id:subject:to:content-type; bh=ya7eL1dn8ATDY2GQ2l4q9OhaUtxb8s5SOPpC/IcmznY=; b=JGsRybqNRxkT0ek242x4dmBW/2s+HbdVOE0U5Zd3xznGG7ImJCxI+HA5FRS2NLj9Pg KvX/GrYnH7S1zV+Pg2zUOgaQ/+pW17L+MB4yJPM3Cb07QSzL0d2TVdqcUkXnReq1v+SS LgfLnVqy+V4Id5+rQ06aw9kSB5abJPC8JPBhi8cxhTH5pWln29JgeF/ay1LZFOQQcMzI jmZ8G48WRsp+2aBQGnCrurYtvKsMd3Kmmhn9afEhHa9o7KdRLwgKqdufR2mxu0pPjfwV cCOpibHoVovpC+yTpUB2DCbdiLsvCDCx8l6S/BoG3QzllWmdy12+iUPimHzqlu7RJQyg uvWQ== X-Gm-Message-State: AG10YORDFSkQWMfi1An3WTaJc/YdL0/aG0h3vYeMxhYQjy/BwLPuMJsU6AwnYe4idGwIVWW1iz9dKdG3DaTW71pn X-Received: by 10.25.31.80 with SMTP id f77mr14632800lff.18.1456415034123; Thu, 25 Feb 2016 07:43:54 -0800 (PST) Reply-To: From: Jean-Pierre Pelletier MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFv41QPz7mKk0YFQt26fcWzK1PeHA== Date: Thu, 25 Feb 2016 10:43:53 -0500 Message-ID: <6fecdc5455863ad2585e3922fdd314e5@mail.gmail.com> Subject: Re: Declarative partitioning To: pgsql-hackers@postgresql.org Content-Type: text/plain; charset=UTF-8 X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Why not based it on "Exclusion Constraint" ? Most discussions as of late seems to focus on Range overlaps which appeal (I would think) is that it supports both "equality" and "overlaps", two popular partitioning schemes. "Equality" as in "value1 = value2" can be implemented with "range overlaps" as "range(value1,value) = range(value,value2)". I would think that Partitioning schemes can be Declarative, Efficient and not restricted to Equality and Overlaps as long as all partitions (of a partitioned table) are using a single partitioning definition expressed as: - An Immutable Expression on tuple columns, in the simplest case a single column - An Operator, in the simplest case, "equality" That seems very close to the semantic of "Constraint Exclusion" as described here: http://thoughts.davisjeff.com/2010/09/25/exclusion-constraints-are-general ized-sql-unique/ If partitioning could be based on EC, it would bring these additional benefits: - The choice of operator as long as it is boolean. commutative and Indexable - The use of Expression/Function and not just bare columns Jean-Pierre Pelletier -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers