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 1hG3Fy-0000U4-Mf for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Apr 2019 15:10:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hG3Fx-0005vP-3j for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Apr 2019 15:10:49 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hG3Fw-0005v4-OK for pgsql-hackers@lists.postgresql.org; Mon, 15 Apr 2019 15:10:48 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hG3Fu-0006t7-Dl for pgsql-hackers@postgresql.org; Mon, 15 Apr 2019 15:10:47 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x3FFAcSU030262; Mon, 15 Apr 2019 11:10:38 -0400 From: Tom Lane To: Stephen Frost cc: Tomas Vondra , Robert Haas , Alvaro Herrera , Konstantin Knizhnik , Ashwin Agrawal , PostgreSQL mailing lists Subject: Re: Zedstore - compressed in-core columnar storage In-reply-to: <20190415123424.GD6197@tamriel.snowman.net> References: <20190409155121.GA4320@alvherre.pgsql> <20190414162210.6djspkmbspbd4els@development> <20190415123424.GD6197@tamriel.snowman.net> Comments: In-reply-to Stephen Frost message dated "Mon, 15 Apr 2019 08:34:24 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30260.1555341038.1@sss.pgh.pa.us> Date: Mon, 15 Apr 2019 11:10:38 -0400 Message-ID: <30261.1555341038@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Stephen Frost writes: > * Tomas Vondra (tomas.vondra@2ndquadrant.com) wrote: >> I think having a colstore in core is important not just for adoption, >> but also for testing and development of the executor / planner bits. > Agreed. TBH, I thought the reason we were expending so much effort on a tableam API was exactly so we *wouldn't* have to include such stuff in core. There is a finite limit to how much stuff we can maintain as part of core. We should embrace the notion that Postgres is an extensible system, rather than build all the tooling for extension and then proceed to dump stuff into core anyway. >> If we have multiple candidates with sufficient code quality, then we may >> consider including both. Dear god, no. regards, tom lane