Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bbwAl-0006wd-L0 for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Aug 2016 20:50:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bbwAk-0006lY-Hk for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Aug 2016 20:50:18 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bbwAj-0006lP-TN for pgsql-hackers@postgresql.org; Mon, 22 Aug 2016 20:50:18 +0000 Received: from smtprelay0190.b.hostedemail.com ([64.98.42.190] helo=smtprelay.b.hostedemail.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bbwAg-0008Cf-P7 for pgsql-hackers@postgresql.org; Mon, 22 Aug 2016 20:50:16 +0000 Received: from filter.hostedemail.com (10.5.19.248.rfc1918.com [10.5.19.248]) by smtprelay05.b.hostedemail.com (Postfix) with ESMTP id C5EE732B04F; Mon, 22 Aug 2016 20:50:13 +0000 (UTC) X-Session-Marker: 616C76686572726540616C76682E6E6F2D69702E6F7267 X-Spam-Summary: 50,0,0,,d41d8cd98f00b204,alvherre@alvh.no-ip.org,:::::::,RULES_HIT:41:355:379:599:967:973:981:982:988:989:1260:1263:1277:1311:1312:1313:1314:1345:1359:1437:1515:1516:1518:1519:1534:1541:1593:1594:1595:1596:1711:1730:1747:1777:1792:2198:2199:2393:2525:2553:2560:2563:2682:2685:2828:2859:2914:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4605:4659:5007:6261:9025:9121:10004:10226:10400:10848:11232:11256:11257:11658:11876:11914:12517:12519:13069:13156:13228:13255:13311:13357:13439:13894:13895:14040:14721:14764:21080:30034:30054:30070:30079:30090,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:1,LUA_SUMMARY:none X-HE-Tag: son17_1ed8ae22a910 X-Filterd-Recvd-Size: 2454 Received: from alvin.alvh.no-ip.org (unknown [216.155.90.98]) (Authenticated sender: alvherre@alvh.no-ip.org) by omf12.b.hostedemail.com (Postfix) with ESMTPA; Mon, 22 Aug 2016 20:50:13 +0000 (UTC) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 1F09B6C5; Mon, 22 Aug 2016 17:50:11 -0300 (CLST) Date: Mon, 22 Aug 2016 17:50:11 -0300 From: Alvaro Herrera To: Robert Haas Cc: Jim Nasby , Aleksander Alekseev , PostgreSQL Hackers Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) Message-ID: <20160822205011.GA149299@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Pg-Spam-Score: -0.4 (/) 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 Robert Haas wrote: > However: > > 1. The number of tables for which we would need to add a duplicate, > unlogged table is formidable. You need pg_attribute, pg_attrdef, > pg_constraint, pg_description, pg_type, pg_trigger, pg_rewrite, etc. > And the backend changes needed so that we used the unlogged copy for > temp tables and the permanent copy for regular tables is probably > really large. Check. This is the most serious issue, IMV. > 2. You can't write to unlogged tables on standby servers, so this > doesn't help solve the problem of wanting to use temporary tables on > standbys. Check. We could think about relaxing this restriction, which would enable the feature to satisfy that use case. (I think the main complication there is the init fork of btrees on those catalogs; other relations could just be truncated to empty on restart.) > 3. While it makes creating temporary tables a lighter-weight > operation, because you no longer need to write WAL for the catalog > entries, there's probably still substantially more overhead than just > stuffing them in backend-local RAM. So the performance benefits are > probably fairly modest. You also save catalog bloat ... These benefits may not be tremendous, but I think they may be good enough for many users. -- Álvaro Herrera 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