Re: disabling an index without deleting it? - Mailing list pgsql-performance

From Tom Lane
Subject Re: disabling an index without deleting it?
Date
Msg-id 10385.1204153217@sss.pgh.pa.us
Whole thread Raw
In response to Re: disabling an index without deleting it?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: disabling an index without deleting it?
Re: disabling an index without deleting it?
List pgsql-performance
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Out of curiosity, couldn't any transaction using a snapshot prior to
> the commit of the DROP continue to use it (just like an uncommited
> DELETE of a row)?  The transaction doing the DROP wouldn't maintain
> it for modifications, which is fine whether it is committed or
> rolled back.  There would just be the matter of "vacuuming" the
> index out of physical existence once all transactions which could
> see it are gone.

You can't just lazily remove the index after the last xact stops using
it; there has to be an agreed synchronization point among all the
transactions.  Otherwise you could have xact A expecting the index to
contain entries from the already-committed xact B, but B thought the
index was dead and didn't bother updating it.

We might be able to do something that would shorten the length of time
that the exclusive lock is held, but AFAICS we couldn't eliminate it
altogether; and I'm unconvinced that merely shortening the interval
is worth much extra complexity.

In the particular case at hand, a planner hook to make it ignore the
index is a far better solution anyway...

            regards, tom lane

pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: disabling an index without deleting it?
Next
From: "Kevin Grittner"
Date:
Subject: Re: disabling an index without deleting it?