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
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 |