Re: Indexes vs. cache flushes - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Indexes vs. cache flushes
Date
Msg-id 87u0c0vfj3.fsf@stark.xeocode.com
Whole thread Raw
In response to Indexes vs. cache flushes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Indexes vs. cache flushes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> This would still support REINDEX (which changes pg_class.relfilenode in
> order to replace the physical file) and ALTER INDEX SET TABLESPACE.
> But you couldn't make any meaningful changes in the definition of an
> index, such as changing its column set, operator classes, partial-index
> predicate, etc, except by dropping and recreating it.
> 
> Now this is true today, and it doesn't seem likely to me that we'd
> ever want to relax it (since any such change would probably require
> rebuilding the index anyway).  But does anyone see that differently?

The only example that comes to mind of something you might want to be able to
twiddle and wouldn't expect to be a slow operation is making a unique index a
non-unique index.

-- 
greg



pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Surrogate keys (Was: enums)
Next
From: Tom Lane
Date:
Subject: Re: Indexes vs. cache flushes