Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YlKDC-0002D1-Ul for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Apr 2015 16:42:51 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YlKDB-0004vA-U0 for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Apr 2015 16:42:49 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YlKD9-0004uo-9r for pgsql-hackers@postgresql.org; Thu, 23 Apr 2015 16:42:47 +0000 Received: from mail-bn1on0085.outbound.protection.outlook.com ([157.56.110.85] helo=na01-bn1-obe.outbound.protection.outlook.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1YlKD2-0008Nr-76 for pgsql-hackers@postgresql.org; Thu, 23 Apr 2015 16:42:46 +0000 Authentication-Results: commandprompt.com; dkim=none (message not signed) header.d=none; Received: from decina.local (70.113.16.71) by BY2PR11MB0678.namprd11.prod.outlook.com (25.163.111.20) with Microsoft SMTP Server (TLS) id 15.1.148.16; Thu, 23 Apr 2015 16:42:31 +0000 Message-ID: <553920F0.8030206@BlueTreble.com> Date: Thu, 23 Apr 2015 11:42:24 -0500 From: Jim Nasby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andres Freund , , Petr Jelinek , Robert Haas CC: Bruce Momjian , Sawada Masahiko , Greg Stark , PostgreSQL-development , Jeff Janes , Subject: Re: Reducing tuple overhead References: <20150423162429.GG3055@alap3.anarazel.de> In-Reply-To: <20150423162429.GG3055@alap3.anarazel.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [70.113.16.71] X-ClientProxiedBy: BLUPR01CA022.prod.exchangelabs.com (25.160.23.12) To BY2PR11MB0678.namprd11.prod.outlook.com (25.163.111.20) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR11MB0678; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(377454003)(479174004)(24454002)(83506001)(77156002)(15975445007)(76176999)(23746002)(4001350100001)(19580395003)(80316001)(2950100001)(33656002)(62966003)(47776003)(99136001)(42186005)(64126003)(50986999)(92566002)(65816999)(65806001)(87266999)(66066001)(5001770100001)(65956001)(86362001)(36756003)(122386002)(50466002)(54356999)(87976001)(46102003)(40100003)(85282002)(336755003)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR11MB0678; H:decina.local; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR11MB0678; BCL:0; PCL:0; RULEID:; SRVR:BY2PR11MB0678; X-Forefront-PRVS: 0555EC8317 X-OriginatorOrg: bluetreble.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2015 16:42:31.1688 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR11MB0678 X-Pg-Spam-Score: -2.1 (--) 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 4/23/15 11:24 AM, Andres Freund wrote: > I do wonder what, in realistic cases, is actually the bigger contributor > to the overhead. The tuple header or the padding we liberally add in > many cases... Assuming you're talking about padding between fields... Several years ago Enova paid Command Prompt to start work on logical column ordering, and part of the motivation for that was to allow re-ordering physical tuples into the most efficient on-disk format possible. I think I did some tests re-arranging some tables into the theoretically most efficient order and measuring heap size. I think there was some modest size improvement, maybe 10-15%? This was several years ago so it's all foggy. Maybe Josh can find some of this in CMD's ticketing system? Aside from that, something else that might be interesting is Tom's recent work on decoupling on-page representation of types from what's passed around internally. That might offer some gains here, even if it's just in reducing the need for alignment. I also wonder if a similar technique would be useful at the tuple level. One possibility would be attempting to compress the tuple before putting it on the page. -- 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