Can't they just let the old index continue to work while generating the new index and then after the new index is created switch? I know the details are more complex but what would be the factor(s) preventing this?
Keith -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rod Taylor Sent: Tuesday, February 10, 2004 2:41 PM To: Robert Treat Cc: Andreas Pflug; [EMAIL PROTECTED]; PostgreSQL Development Subject: Re: [HACKERS] MS SQL features for new version On Tue, 2004-02-10 at 15:37, Robert Treat wrote: > On Tue, 2004-02-10 at 13:20, Rod Taylor wrote: > > > >http://www.microsoft.com/sql/yukon/productinfo/top30features.asp > > > > > Notice the Snapshot Isolation. Sounds like MVCC for MSSQL? > > > > Actually, the one I noticed was the ability to add or rebuild > > indexes on the fly. That is a pretty slick trick. > > > > I was trying to decide how much better this was than > > BEGIN; > DROP INDEX foo ON bar; > CREATE INDEX foo ON bar; > COMMIT; Well.. If thats a big table, you've just blocked selects, updates, delete, inserts, etc. against that table for the duration of the index recreation. Their text indicates that all activity on the table will not be blocked during the creation of a new index on that table. To me, that makes it a slick trick. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
