Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: ALTER INDEX set fillfactor


  • From: "Dave Page" <dpage(at)postgresql(dot)org>
  • To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
  • Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
  • Subject: Re: ALTER INDEX set fillfactor
  • Date: Sat, 6 Oct 2007 17:45:52 +0100
  • Message-id: <200710061745520000(at)074520261>


> ------- Original Message -------
> From: Simon Riggs <simon(at)2ndquadrant(dot)com>
> To: Dave Page <dpage(at)postgresql(dot)org>
> Sent: 06/10/07, 08:33:30
> Subject: Re: [pgadmin-hackers] ALTER INDEX set  fillfactor
> 
> On Fri, 2007-10-05 at 21:24 +0100, Dave Page wrote:
> > Simon Riggs wrote:
> 
> > > It would be even better if there was an option to do that CONCURRENTLY,
> > > i.e. add the new index and then drop the old one afterwards. (It's
> > > unfortunate that there isn't a REINDEX concurrently, but there isn't
> > > yet).
> > 
> > Funny - I suggested that to Greg just the other day...
> 
> Sorry, I meant in the absence of REINDEX concurrently, we can issue:
> 
> CREATE INDEX CONCURRENTLY newindex
> DROP INDEX oldindex
> 
> on each index on the table in turn, which does the same thing.

CIC can't be run in a transaction block, so how do we queue up the drop & rename to run after it completes? Given the changes to VACUUM & CREATE DATABASE/TABLESPACE in 8.3 I would imagine it won't run in a multi-statement query either now.

/D



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group