Re: REINDEX checking of index constraints

From: Noah Misch <noah(at)leadboat(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: REINDEX checking of index constraints
Date: 2013-07-23 00:58:12
Message-ID: 20130723005812.GA151281@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 21, 2013 at 01:47:00PM -0700, Josh Berkus wrote:
> On 07/21/2013 11:30 AM, Josh Berkus wrote:
> >> Attached patch just restores the old behavior. Would it be worth preserving
> >> the ability to fix an index consistency problem with a REINDEX independent
> >> from related heap consistency problems such as duplicate keys?
> >
> > I would love to have two versions of REINDEX, one which validated and
> > one which didn't. Maybe a ( validate off ) type check?
>
> Cancel this. I just did some tests, and there amount of time required
> for the validation (at least, in simple two-column table test) is < 10%
> of the time required to reindex in general. At that difference, we
> don't need two options.
>
> Unless you're asking if we want a command to check the index validity
> without rebuilding it? That might be more valuable ...

I meant to ask whether, instead of reverting the accidental behavior change,
we should do something like leave the behavior and change the documentation
instead. I personally vote "no", but that alternative seemed credible enough
to justify mentioning it. Something more radical, like a new UI, would be a
separate patch.

Thanks,
nm

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2013-07-23 01:21:52 Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)
Previous Message Greg Smith 2013-07-23 00:50:15 Re: [9.4 CF 1] The Commitfest Slacker List