Re: When/if to Reindex

From: "Steven Flatt" <steven(dot)flatt(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Bill Moran" <wmoran(at)collaborativefusion(dot)com>, "Vivek Khera" <vivek(at)khera(dot)org>, "Pgsql performance" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: When/if to Reindex
Date: 2007-08-22 16:55:28
Message-ID: 357fa7590708220955h441cd75ap4c0f0342a1c30a14@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

>
> It makes more sense for us to have ~1 hour's worth of reindexing
> afterwards during which read performance on that partition is "compromised".
>

So, based on the docs, I was expecting read performance to be compromised
during a reindex, specifically reads would not be allowed to use the index:

"REINDEX locks out writes but not reads of the index's parent table. It also
takes an exclusive lock on the specific index being processed, which will
block reads that attempt to use that index."

However I'm seeing that all readers of that table are blocked until the
reindex finishes, even reads that do not attempt to use the index. Is this
a problem with the docs or a bug?

I'm considering creating a new index with the same definition as the first
(different name), so while that index is being created, read access to the
table, and the original index, is not blocked. When the new index is
created, drop the original index and rename the new index to the original,
and we've essentially accomplished the same thing. In fact, why isn't
reindex doing this sort of thing in the background anways?

Thanks,
Steve

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Oleg Bartunov 2007-08-22 18:48:44 Re: Fast tsearch2, trigram matching on short phrases
Previous Message Steinar H. Gunderson 2007-08-22 16:29:50 Re: Fast tsearch2, trigram matching on short phrases