Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aMcBm-0008DQ-LF for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Jan 2016 13:55:47 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aMcBm-0007Ca-88 for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Jan 2016 13:55:46 +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) (envelope-from ) id 1aMcAQ-0005et-SD for pgsql-hackers@postgresql.org; Fri, 22 Jan 2016 13:54:22 +0000 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aMcAM-0005NO-Om for pgsql-hackers@postgresql.org; Fri, 22 Jan 2016 13:54:22 +0000 Received: by mail-wm0-x22f.google.com with SMTP id u188so19675403wmu.1 for ; Fri, 22 Jan 2016 05:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=gWvnSvJtPZBgrfAJxznlm0w7UTD1mbus+WcAbywTcMM=; b=XIfFCOLS4KyApvzejcSQiOML0jQisA+717of1wFlRauNeClbBayCSUxb6dapB//hdb g3AZwO6+ie6PdvPj0ENPtJ8g5ms41D5XfeYeo2woLSqliPYiR74aDYzWq+n3KDMbz8rM CsYWs/YFtYfw3jyy/dY142//wOu/Cwd02lOMyKRc1Ir+DbuhSlEUSw085iF2Bb9ZgUY+ S/CHCTZ6KNcQZNGA5QTxcGlM3cAJoc8jWd8HBbTQJZQN5B4CopfEQiNdYeP/lqZiWtGZ BlTlsyTfYEWTKIpHXR4fbZhABr2xiDCP29XZtRt3c3vezhfBhNE/50NPn3jz5fd/PRX6 u1fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=gWvnSvJtPZBgrfAJxznlm0w7UTD1mbus+WcAbywTcMM=; b=FRVGYRootRUxBK/0PPwceRRhDh6Kq1BEWbLMNLo/r0e29vEyowZ9Mg6IwSiqsNtP8L dNwv1P8GO7pAyNTwilhTE7PonQURQ640UvaHqBosAGlyum+hz0WIw9kDJwFEQqbAsCA7 46O2pNGV3bwQgHZKndSvxgbr7/C6MTX8AOHypcJRKsEPdO7anxYk4aJyJlb18tnJncU2 EJcmO6HPcjS+vKoITTvPRVgaYki5cHaflGbkm2qy4SxuDNOgcfaZWRSVlEE5Zh7C/N6l aSdvH0E14Cq873gko2ZJjY4tI8biblPdXzLW5rfsT1hPahbSgruauGlsUYUlcyzLnSNS co0Q== X-Gm-Message-State: AG10YOSLY0OFA+nqv+mxx0QLbrw3KVc8jwqsiClKz0PbUo4FGrFVTHIZgjU2NP3ahWG0rhEtGlZ27l8bKNGFr3XF13STr7nD0QDjkGx/t41Ai+FDkMW+/XETvnxWjG0ksq47c8TNzJNe0xTfa7pTYl0cHQ21SQnPKkyDxt72nJfpx+kBbkRkl6SyWi/ygWnfYuZRM4pikV3e X-Received: by 10.28.63.200 with SMTP id m191mr3886600wma.67.1453470857278; Fri, 22 Jan 2016 05:54:17 -0800 (PST) Received: from [10.137.1.13] (ip-78-45-216-26.net.upcbroadband.cz. [78.45.216.26]) by smtp.gmail.com with ESMTPSA id c185sm3056419wma.5.2016.01.22.05.54.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2016 05:54:16 -0800 (PST) Subject: Re: Declarative partitioning To: pgsql-hackers@postgresql.org References: <55D3093C.5010800@lab.ntt.co.jp> From: Tomas Vondra Message-ID: <56A23484.4000504@2ndquadrant.com> Date: Fri, 22 Jan 2016 14:54:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55D3093C.5010800@lab.ntt.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) 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 Hi Amit, thanks for working on this. Seems the last version of the patch was submitted more than 2 months ago and I believe large parts of it will get reworked based on the extensive discussion on this list, so I haven't looked at the code at all. I'd like to comment on the one thing and that's the syntax. It seems to me we're really trying to reinvent the wheel and come up with our own version of the syntax. Is there a particular reason why not to look at the syntax of the other databases and adapt as much of the existing syntax as possible? I think that's for a few reasons - firstly it makes the life much easier for the DBAs and users who are either migrating to PostgreSQL or have to manage a mix of databases. Secondly, it serves as a valuable source of engineering info, preventing the "I haven't thought of this use case" problem. An example of this is the proposed syntax for adding a partition CREATE TABLE measurement_fail PARTITION OF measurement FOR VALUES START ('2006-02-15') END ('2006-03-01'); which seems a bit awkward as both the databases I'm familiar with (Oracle and Sybase) use ALTER TABLE to do this ALTER TABLE measurement ADD PARTITION measurement_fail VALUES LESS THAN ( ... ) And so on for the other commands. That being said, I entirely agree with Simon (and others) that getting the planner part work is the crucial part of the patch. But I also think that a proper abstraction (thanks to good syntax) may be a valuable hint how to define the catalogs and such. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers