Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 4BCDD2E0047 for ; Tue, 26 Feb 2008 22:48:12 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 86243-10 for ; Tue, 26 Feb 2008 22:48:09 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by postgresql.org (Postfix) with ESMTP id 08F682E0045 for ; Tue, 26 Feb 2008 22:48:08 -0400 (AST) Received: by rv-out-0910.google.com with SMTP id g13so1800911rvb.43 for ; Tue, 26 Feb 2008 18:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=raWtfYDS/R3IGptaXk2c+nof0Jn6Mo/STpr0yaLZuO0=; b=A9V0wooSzfaDAz63t/gag3ntiiJviqb2bhrmu2jlvg4NVyZr4EKdE5d5mXtmfE1xLpEBJvATbW6TVB4O3tsVtRk8TN/okZIIiuGAPbGArhtzBe7d2LS49F4YwmATRQPP+3LyvMWkRhaIlObz8Q4Nj2cMdU+EZzwJNTbIxzQErhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZFxCs/sTiQSlDIAoEXNn6oqCtk6JXeBYN2hMr3w59vf7gRv4TNwFfqlVlLYRP5w2Z2HBRnQo+7lEdP4g7Im5U+RWp4vtfFtxU3PYGM00BLhH6OePUOAUrjCCbDwEkzbc9IVj2tva80m4GOZXssK32VziJZEHHQKZwHtTBWfIrG0= Received: by 10.141.142.15 with SMTP id u15mr3993376rvn.66.1204080486605; Tue, 26 Feb 2008 18:48:06 -0800 (PST) Received: by 10.141.128.7 with HTTP; Tue, 26 Feb 2008 18:48:06 -0800 (PST) Message-ID: <684362e10802261848j79686752k6dfbe032e985b131@mail.gmail.com> Date: Wed, 27 Feb 2008 08:48:06 +0600 From: "Markus Bertheau" To: "Tom Lane" Subject: Re: disabling an index without deleting it? Cc: "Joshua D. Drake" , "Scott Marlowe" , "Peter Koczan" , pgsql-performance In-Reply-To: <9050.1204064560@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4544e0330802261246t574167fdpc47629d1bbe64fed@mail.gmail.com> <20080226130339.64bd4ec3@commandprompt.com> <9050.1204064560@sss.pgh.pa.us> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200802/361 X-Sequence-Number: 28903 2008/2/27, Tom Lane : > "Joshua D. Drake" writes: > > "Scott Marlowe" wrote: > > >> begin; > >> drop index abc_dx; > >> select .... > >> rollback; > >> > >> and viola, your index is still there. note that there are likely some > >> locking issues with this, so be careful with it in production. But on > >> a test box it's a very easy way to test various indexes. > > > Wouldn't you also bloat the index? > > > No, what makes you think that? The index won't change at all in the > above example. The major problem is, as Scott says, that DROP INDEX > takes exclusive lock on the table so any other sessions will be locked > out of it for the duration of your test query. Why is the exclusive lock not taken later, so that this method can be used reasonably risk-free on production systems? From what I understand the later would be either a statement that would (potentially) be modifying the index, like an UPDATE or an INSERT, or actual transaction commit. If none of these occur and the transaction is rollbacked, the exclusive lock doesn't have to be taken at all. Markus -- Markus Bertheau Blog: http://www.bluetwanger.de/blog/