Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YnaUF-0001Eo-Md for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Apr 2015 22:29:47 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YnaUE-0001qH-Qp for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Apr 2015 22:29:46 +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 1YnaUD-0001q7-6c for pgsql-hackers@postgresql.org; Wed, 29 Apr 2015 22:29:45 +0000 Received: from mail-bn1on0065.outbound.protection.outlook.com ([157.56.110.65] 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 1YnaU9-0007DW-Ro for pgsql-hackers@postgresql.org; Wed, 29 Apr 2015 22:29:43 +0000 Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; Received: from decina.attlocal.net (2602:306:ce8b:3460:3598:3a7:a253:8705) by SN1PR11MB0687.namprd11.prod.outlook.com (25.163.207.145) with Microsoft SMTP Server (TLS) id 15.1.148.16; Wed, 29 Apr 2015 22:29:34 +0000 Message-ID: <55415B4B.5000203@BlueTreble.com> Date: Wed, 29 Apr 2015 17:29:31 -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: Robert Haas CC: Amit Kapila , Petr Jelinek , Andres Freund , hlinnaka , 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> <553AA753.9010103@BlueTreble.com> <553EA399.1010508@BlueTreble.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [2602:306:ce8b:3460:3598:3a7:a253:8705] X-ClientProxiedBy: CO2PR05CA033.namprd05.prod.outlook.com (10.141.241.161) To SN1PR11MB0687.namprd11.prod.outlook.com (25.163.207.145) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR11MB0687; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR11MB0687; BCL:0; PCL:0; RULEID:; SRVR:SN1PR11MB0687; X-Forefront-PRVS: 05610E64EE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(24454002)(377454003)(51704005)(479174004)(42186005)(50466002)(36756003)(23676002)(122386002)(40100003)(59896002)(15975445007)(65806001)(110136002)(64126003)(99136001)(62966003)(4001350100001)(2950100001)(77156002)(53416004)(65956001)(46102003)(19580405001)(80316001)(83506001)(87266999)(92566002)(87976001)(47776003)(93886004)(33656002)(65816999)(86362001)(1411001)(76176999)(50986999)(19580395003)(54356999)(5001960100002)(3826002)(85282002)(336755003)(18886065003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR11MB0687; H:decina.attlocal.net; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-OriginatorOrg: bluetreble.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2015 22:29:34.2300 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR11MB0687 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/29/15 12:18 PM, Robert Haas wrote: > On Mon, Apr 27, 2015 at 5:01 PM, Jim Nasby wrote: >> The problem with just having the value is that if *anything* changes between >> how you evaluated the value when you created the index tuple and when you >> evaluate it a second time you'll corrupt your index. This is actually an >> incredibly easy problem to have; witness how we allowed indexing >> timestamptz::date until very recently. That was clearly broken, but because >> we never attempted to re-run the index expression to do vacuuming at least >> we never corrupted the index itself. > > True. But I guess what I don't understand is: how big a deal is this, > really? The "uncorrupted" index can still return wrong answers to > queries. The fact that you won't end up with index entries pointing > to completely unrelated tuples is nice, but if index scans are missing > tuples that they should see, aren't you still pretty hosed? Maybe, maybe not. You could argue it's better to miss some rows than have completely unrelated ones. My recollection is there's other scenarios where this causes problems, but that's from several years ago and I wasn't able to find anything on a quick search of archives. I've wondered the same in the past and Tom had reasons it was bad, but perhaps they're overstated. -- 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