On Sat, Mar 4, 2017 at 9:34 AM, Andres Freund <and...@anarazel.de> wrote: > On March 4, 2017 1:16:56 AM PST, Robert Haas <robertmh...@gmail.com> wrote: >>Maybe. But it looks to me like this patch is going to have >>considerably more than its share of user-visible warts, and I'm not >>very excited about that. I feel like what we ought to be doing is >>keeping the index OID the same and changing the relfilenode to point >>to a newly-created one, and I attribute our failure to make that >>design work thus far to insufficiently aggressive hacking. > > We literally spent years and a lot of emails waiting for that to happen. > Users now hack up solutions like this in userspace, obviously a bad solution. > > I agree that'd it be nicer not to have this, but not having the feature at > all is a lot worse than this wart.
IMHO, REINDEX itself is implemented in a way that is conceptually pure, and yet quite user hostile. I tend to tell colleagues that ask about REINDEX something along the lines of: Just assume that REINDEX is going to block out even SELECT statements referencing the underlying table. It might not be that bad for you in practice, but the details are arcane such that it might as well be that simple most of the time. Even if you have time to listen to me explain it all, which you clearly don't, you're still probably not going to be able to apply what you've learned in a way that helps you. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers