Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPa6u-0004t1-4R for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Jun 2017 19:55:48 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dPa6t-0000lW-HU for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Jun 2017 19:55:47 +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_2) (envelope-from ) id 1dPa6s-0000k6-33 for pgsql-hackers@postgresql.org; Mon, 26 Jun 2017 19:55:46 +0000 Received: from mail-wr0-x234.google.com ([2a00:1450:400c:c0c::234]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dPa6m-0005ZH-Vl for pgsql-hackers@postgresql.org; Mon, 26 Jun 2017 19:55:44 +0000 Received: by mail-wr0-x234.google.com with SMTP id r103so149670525wrb.0 for ; Mon, 26 Jun 2017 12:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Gl4ozc7XBOJDxxR55oRE3Ufor+jCzQ47eiJsdZmbNWw=; b=Ed3RB+lBN9y+4OFlMo5iQrZ/X/BRcJUYyVMRKVmic7ShyESNNy7LdKJhUbIZgLCFJ+ xYU+Sxx9DmX878EPq6fAPFsc4rgfUx3imcbxeMRk8s34oeB9Fz9C9YlX5/eO95wTMWTG dMcHKhhjJBvvX8RbF/TT4sl/8xFYyIyE42lTz9AA2yTxFvz/fGeWyxDlB36sgRDESGk1 zTJCLC4I2WwEqoVjiSljpBthqhZcNp+8DKECYwMxR5r5HfIY5Hd1rRUcwfXwwUHam8xq qumwmkR+zVWSl758UbuxpD6CQxw+PWLp2GEd+EsePQqIJdpoNdUQMW5lT2mCyyVyLQPa v1AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Gl4ozc7XBOJDxxR55oRE3Ufor+jCzQ47eiJsdZmbNWw=; b=Nl6TZrgLZcGlzCem+gm63g3vEeyuLy1c4WrfyRh/RVoP3vkkgdh1ScBXrBbgVurjR6 LH6elmEB4VJb9sKQhYwWWcGtuhq+Rr9GEnPuJNjmS6ZTtP589w/Xw22AcPaRnNzfeOOy Sa5Hixl8So1zbxlVihpNcn2O7l66RDJ0f3B2dDtZmlBaB0CzNGluhkl3Jy8CYji87nwk ci9IHsrTC5+tjM3bGsgoeWt9RVr7AuoiJFT9E8ITmsFVPUIUNcGJxhaAZ2KDLuoQ4aYr EWbZjpcjTW8CKI3LXbPIfmx8BqoB+6RACmh4DNEyRqB9tKZZiktGzfevvzUxu1izHH/d K5XQ== X-Gm-Message-State: AKS2vOyiX7qUut4lIOFvPtqkPP+m64Yq4xF0O/CL4N/T4QEhRhZVu46a SXqm2jYCoI137BOaMi2bLKs2Y1fJsCLeTIThcp5hq+fFq+WKNMVRb9g2nLWM0uM/N3+7T6EmJ5Q GfpbOBJifjh3sRlN9knGxWCKJ3vNQaJKRBSkno7l2uR1F7V2N/xR4midIlsDoHfkBUaGouFG87s ogUw== X-Received: by 10.223.136.109 with SMTP id e42mr14256285wre.81.1498506938450; Mon, 26 Jun 2017 12:55:38 -0700 (PDT) Received: from [10.137.1.17] ([212.69.41.185]) by smtp.gmail.com with ESMTPSA id i22sm13025772wrb.30.2017.06.26.12.55.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 12:55:37 -0700 (PDT) Subject: Re: Pluggable storage To: Alexander Korotkov , Julien Rouhaud Cc: Teodor Sigaev , Michael Paquier , Robert Haas , Haribabu Kommi , Alvaro Herrera , Pg Hackers References: <20160824182201.GA232997@alvherre.pgsql> <20161013202642.ksiuyx72gu6wgupf@alvherre.pgsql> <8b2510f0-ab89-dbf1-5b1c-5d686a5e33b8@sigaev.ru> <9b5728fc-c266-5f71-9a69-7668ad231e05@2ndquadrant.com> <62e28066-8063-e1f5-28dc-651adc11ca1b@dalibo.com> From: Tomas Vondra Message-ID: <61caf61f-da05-76f5-0aa2-cdee4dd8efd7@2ndquadrant.com> Date: Mon, 26 Jun 2017 21:55:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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, On 06/26/2017 05:18 PM, Alexander Korotkov wrote: > Hackers, > > I see that design question for PostgreSQL pluggable storages is very > hard. IMHO it's mostly expected to be hard. Firstly, PostgreSQL is a mature product with many advanced features, and reworking a low-level feature without breaking something on top of it is hard by definition. Secondly, project policies and code quality requirements set the bar very high too, I think. > BTW, I think it worth analyzing existing use-cases of pluggable > storages. I think that the most famous DBMS with pluggable storage API > is MySQL. This why I decided to start with it. I've added > MySQL/MariaDB section on wiki page. > https://wiki.postgresql.org/wiki/Future_of_storage#MySQL.2FMariaDB > It appears that significant part of MySQL storage engines are misuses. > MySQL lacks of various features like FDWs or writable views and so on. > This is why developers created a lot of pluggable storages for that > purposes. We definitely don't want something like this in PostgreSQL > now. I created special resume column where I expressed whether it > would be nice to have something like this table engine in PostgreSQL. > I don't want to discourage you, but I'm not sure how valuable this is. I agree it's valuable to have a an over-view of use cases for pluggable storage, but I don't think we'll get that from looking at MySQL. As you noticed, most of the storage engines are misuses, so it's difficult to learn anything valuable from them. You can argue that using FDWs to implement alternative storage engines is a misuse too, but at least that gives us a valid use case (columnar storage implemented using FDW). If anything, the MySQL storage engines should serve as a cautionary tale how not to do things - there's also a plenty of references in the MySQL "Restrictions and Limitations" section of the manual: https://downloads.mysql.com/docs/mysql-reslimits-excerpt-5.7-en.pdf 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