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 1hG79J-0003TG-Of for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Apr 2019 19:20:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hG79I-0007kr-DF for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Apr 2019 19:20:12 +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 1hG79H-0007kd-8y for pgsql-hackers@lists.postgresql.org; Mon, 15 Apr 2019 19:20:12 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hG79E-00048c-6q for pgsql-hackers@postgresql.org; Mon, 15 Apr 2019 19:20:10 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 615212432D; Mon, 15 Apr 2019 15:20:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 15 Apr 2019 15:20:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=/7istb9IUamQ8mayRRVlXQHEoGH bzKbHLD4pb+8/vXY=; b=7VTqg0KGiarojLWbFrzRhnfyTJUN02rW3AS8aVTY1ND JbCcTuQ/4F7AD9QLmb45lKhq7rLc9pDzTYD/qfKDOrCnUFL8fztZovi9cMvxeOdI qk3Gtl6tgYhfP85uf7CouyM8RYs8CynDdznkUShb75con7rVXunXXSELPXf3aWtF gOmR/9LG5Bdzgbf+SC2EoblNNFe/cPDLYfOO09AoX2reoV7T1lE9EhZ377rPX2Kn WXwXT8qTMvch+kyM60T+rwMvEvpsb5CpEEElKymZldqbi2OwWfiS4vAqnhpD6ZIg zQ8XG9ToxNNEGKP9h9eAjbnLUQLdkoNTVu/x9wxXKlw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=/7istb 9IUamQ8mayRRVlXQHEoGHbzKbHLD4pb+8/vXY=; b=kCz7G8IYfLDRzs5ett3c6u lXTlegbAmunc1tZBRRRAukrd8UTOyJWv1lEkCM1f6J5vgkQFf01DYUC7rc6yuhmK PCGbzirwerqDOydBimr9FSKvWr81tUlzNPXDIf8c/iDZ853LjMmA7EDPMwSoVCpJ lZsg7FmSrlnVweHNb8z5Y6Jv/Y5fhoRGgT2KmjKeaq9xWhTwMMKvBz1H4qtFb6Ps y9cTD89cWlFdWyAWFJCIhEtsxXUZGkpZu94mPnTMRXo4QvYGVw5nXqGrO96unpCB 4/wBOGc46f5V6x6KehaNykbxWgJ9u9FOIdT3EqLJ7QY9IkzFAZMhvIrAvGNVXFaw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrvdelgddufeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeetnhgurhgv shcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucfkpheple ekrddvuddtrddugedtrddujedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhgurhgv shesrghnrghrrgiivghlrdguvgenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from intern.anarazel.de (c-98-210-140-171.hsd1.ca.comcast.net [98.210.140.171]) by mail.messagingengine.com (Postfix) with ESMTPA id 19D1AE454F; Mon, 15 Apr 2019 15:20:06 -0400 (EDT) Date: Mon, 15 Apr 2019 12:20:04 -0700 From: Andres Freund To: Tom Lane Cc: Robert Haas , Stephen Frost , Tomas Vondra , Alvaro Herrera , Konstantin Knizhnik , Ashwin Agrawal , PostgreSQL mailing lists Subject: Re: Zedstore - compressed in-core columnar storage Message-ID: <20190415192004.od3paxoo5rlogmm4@alap3.anarazel.de> References: <20190409155121.GA4320@alvherre.pgsql> <20190414162210.6djspkmbspbd4els@development> <20190415123424.GD6197@tamriel.snowman.net> <30261.1555341038@sss.pgh.pa.us> <20789.1555353343@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20789.1555353343@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2019-04-15 14:35:43 -0400, Tom Lane wrote: > Yeah, and that's something I've regretted more than once; I think SP-GiST > is a sterling example of something that isn't nearly useful enough in the > real world to justify the amount of maintenance effort we've been forced > to expend on it. You might trawl the commit logs to get a sense of the > amount of my own personal time --- not that of the original submitters --- > that's gone into that one module. Then ask yourself how much that model > will scale, and what other more-useful things I could've accomplished > with that time. I do agree that the [group of] contributor's history of maintaining such work should play a role. And I think that's doubly so with a piece as crucial as a table AM. But: > We do need to limit what we accept into core PG. I do not buy your > argument that users expect everything to be in core. Or more accurately, > the people who do think that way won't be using PG anyway --- they'll > be using MSSQL because it comes from their OS vendor. I don't think anybody disagrees with that, actually. Including Robert. But I don't think it follows that we shouldn't provide things that are either much more reasonably done in core like a pooler (authentication / encryption; infrastructure for managing state like prepared statements, GUCs; avoiding issues of explosion of connection counts with pooling in other places), are required by a very significant portion of our users (imo the case for a columnar store or a row store without the architectural issues of heap), or where it's hard to provide the necessary infrastructure without an in-core user (imo also the case with columnar, due to the necessary planner / executor improvements for fast query execution). We also have at times pretty explicitly resisted making crucial pieces of infrastructure usable outside of core. E.g. because it's legitimately hard (grammar extensibility), or because we'd some concerns around stability and the exact approach (WAL - the generic stuff is usable for anything that wants to even be somewhat efficient, some xlog integration). So there's several types of extensions that one realistically cannot do out of core, by our choice. Greetings, Andres Freund