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
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 |