Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XwySh-0007lc-0z for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Dec 2014 19:22:43 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XwySg-0001lx-Dp for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Dec 2014 19:22:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XwySf-0001lq-6q for pgsql-hackers@postgresql.org; Fri, 05 Dec 2014 19:22:41 +0000 Received: from mail-by2on0619.outbound.protection.outlook.com ([2a01:111:f400:fc0c::619] helo=na01-by2-obe.outbound.protection.outlook.com) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XwySV-0002pc-NK for pgsql-hackers@postgresql.org; Fri, 05 Dec 2014 19:22:40 +0000 Received: from decina.local (24.55.12.91) by BY1PR11MB0342.namprd11.prod.outlook.com (25.160.206.155) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 5 Dec 2014 19:22:22 +0000 Message-ID: <548205E5.7020505@BlueTreble.com> Date: Fri, 5 Dec 2014 13:22:13 -0600 From: Jim Nasby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Amit Langote , 'Amit Kapila' CC: 'Robert Haas' , 'Andres Freund' , 'Alvaro Herrera' , 'Bruce Momjian' , 'Pg Hackers' Subject: Re: On partitioning References: <20140829155607.GF7705@eldon.alvh.no-ip.org> <20141028100629.GE2639@awork2.anarazel.de> <053501cffa30$ecdf8700$c69e9500$@lab.ntt.co.jp> <066501cffd52$3d919390$b8b4bab0$@lab.ntt.co.jp> <032601d00471$ea6f4280$bf4dc780$@lab.ntt.co.jp> <04da01d00917$2dde1010$899a3030$@lab.ntt.co.jp> <015b01d00eab$56d37700$047a6500$@lab.ntt.co.jp> <0! 1ca01d00f81$74f2c750$5e d855f0$@lab.ntt.co.jp> <028401d01058$b4b19dd0$1e14d970$@lab.ntt.co.jp> <029e01d0106f$d511eb40$7f35c1c0$@lab.ntt.co.jp> In-Reply-To: <029e01d0106f$d511eb40$7f35c1c0$@lab.ntt.co.jp> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [24.55.12.91] X-ClientProxiedBy: DM2PR10CA0069.namprd10.prod.outlook.com (10.141.241.37) To BY1PR11MB0342.namprd11.prod.outlook.com (25.160.206.155) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR11MB0342; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY1PR11MB0342; X-Forefront-PRVS: 04163EF38A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(199003)(377454003)(479174003)(24454002)(189002)(107046002)(50466002)(59896002)(54356999)(92566001)(50986999)(97736003)(64126003)(106356001)(4396001)(21056001)(77156002)(105586002)(62966003)(83506001)(99136001)(23676002)(99396003)(40100003)(120916001)(122386002)(33656002)(65816999)(93886004)(76176999)(80316001)(46102003)(87266999)(19580395003)(86362001)(101416001)(36756003)(42186005)(20776003)(47776003)(65956001)(66066001)(65806001)(64706001)(87976001)(15975445007)(31966008)(68736005)(85282002)(336755003)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR11MB0342; H:decina.local; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY1PR11MB0342; X-OriginatorOrg: bluetreble.com X-Pg-Spam-Score: -1.9 (-) 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 On 12/5/14, 3:42 AM, Amit Langote wrote: >> > I think you are right. I think in this case we need something similar >> >to column pg_index.indexprs which is of type pg_node_tree(which >> >seems to be already suggested by Robert). So may be we can proceed >> >with this type and see if any one else has better idea. > One point raised about/against pg_node_tree was the values represented therein would turn out to be too generalized to be used with advantage during planning. But, it seems we could deserialize it in advance back to the internal form (like an array of a struct) as part of the cached relation data. This overhead would only be incurred in case of partitioned tables. Perhaps this is what Robert suggested elsewhere. In order to store a composite type in a catalog, we would need to have one field that has the typid of the composite, and the field that stores the actual composite data would need to be a "dumb" varlena that stores the composite HeapTupleHeader. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers