Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YlkCz-0002Bp-Ao for pgsql-hackers@arkaria.postgresql.org; Fri, 24 Apr 2015 20:28:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YlkCy-0003Pn-Fe for pgsql-hackers@arkaria.postgresql.org; Fri, 24 Apr 2015 20:28:20 +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 1YlkCv-0003MO-VW for pgsql-hackers@postgresql.org; Fri, 24 Apr 2015 20:28:18 +0000 Received: from mail-bl2on0080.outbound.protection.outlook.com ([65.55.169.80] helo=na01-bl2-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 1YlkCt-0004tQ-Bu for pgsql-hackers@postgresql.org; Fri, 24 Apr 2015 20:28:16 +0000 Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; Received: from decina.local (70.113.16.71) by CY1PR11MB0684.namprd11.prod.outlook.com (25.163.236.22) with Microsoft SMTP Server (TLS) id 15.1.148.16; Fri, 24 Apr 2015 20:28:07 +0000 Message-ID: <553AA753.9010103@BlueTreble.com> Date: Fri, 24 Apr 2015 15:28:03 -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: Amit Kapila CC: Petr Jelinek , Andres Freund , , Robert Haas , Bruce Momjian , Sawada Masahiko , Greg Stark , PostgreSQL-development , Jeff Janes Subject: Re: Reducing tuple overhead References: <20150423162429.GG3055@alap3.anarazel.de> <553921B1.7080204@2ndquadrant.com> <5539491C.6040405@BlueTreble.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [70.113.16.71] X-ClientProxiedBy: SN1PR0701CA0032.namprd07.prod.outlook.com (25.162.96.42) To CY1PR11MB0684.namprd11.prod.outlook.com (25.163.236.22) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR11MB0684; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(479174004)(377454003)(24454002)(87976001)(110136001)(47776003)(83506001)(76176999)(80316001)(65816999)(54356999)(87266999)(46102003)(62966003)(77156002)(50986999)(36756003)(59896002)(93886004)(92566002)(122386002)(40100003)(42186005)(2950100001)(23746002)(66066001)(65956001)(65806001)(86362001)(4001350100001)(19580395003)(50466002)(33656002)(15975445007)(551934003)(336755003)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR11MB0684; H:decina.local; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010)(3002001); SRVR:CY1PR11MB0684; BCL:0; PCL:0; RULEID:; SRVR:CY1PR11MB0684; X-Forefront-PRVS: 05568D1FF7 X-OriginatorOrg: bluetreble.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2015 20:28:07.0873 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR11MB0684 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 10:40 PM, Amit Kapila wrote: > I agree with you and what I think one of the major reasons of bloat is that > Index segment doesn't have visibility information due to which clearing of > Index needs to be tied along with heap. Now if we can move transaction > information at page level, then we can even think of having it in Index > segment as well and then Index can delete/prune it's tuples on it's own > which can reduce the bloat in index significantly and there is a benefit > to Vacuum as well. I don't see how putting visibility at the page level helps indexes at all. We could already put XMIN in indexes if we wanted, but it won't help, because... > Now this has some downsides as well like Delete > needs to traverse Index segment as well to Delete mark the tuples, but > I think the upsides of reducing bloat can certainly outweigh the downsides. ... which isn't possible. You can not go from a heap tuple to an index tuple. This has been discussed in the past. If we could do that then vacuum would become REALLY cheap compared to today. BTW, before actually tackling anything we should try and get more data from Robert/Jan about where the extra 80% came from. We don't know if it's indexes or what. -- 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