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: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Rod Taylor
Sent: Tuesday, February 10, 2004 2:41 PM
To: Robert Treat
Cc: Andreas Pflug; shridhar@frodo.hserus.net; 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 majordomo@postgresql.org