From: | Vivek Khera <khera(at)kcilink(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Commercial postgresql |
Date: | 2003-09-02 14:19:06 |
Message-ID: | x7llt7b7dx.fsf@yertle.int.kciLink.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>>>>> "SD" == Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> writes:
>> second largest table, and 5 per index on the third largest, then about
>> 90 seconds total for the rest of the tables ;-)
SD> Umm.. Since you have only 2.7GB of data, all inclusive, would it
SD> be real downtime if you reindex in a transaction, assuming the
SD> "downtime" was not due to crunch of IO bandwidth..
Reindexing a table takes an exclusive table lock. If I did it inside
a transaction, wouldn't it still take that lock and block out all
other access?
I just did one index at a time, waited a few minutes did the next for
my big tables, than just reindexed the others all in a row. Last time
I did this must have been 9 or 10 months. One index went from 500000
pages to under 220000. Right now the system is screamingly fast.
Perhaps I need to write an 'auto_reindex' script to notice when this
is necessary and schedule one to run at the wee hours in the morning
at the end of the week...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera(at)kciLink(dot)com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
From | Date | Subject | |
---|---|---|---|
Next Message | Shridhar Daithankar | 2003-09-02 14:28:27 | Re: Commercial postgresql |
Previous Message | psql-mail | 2003-09-02 14:14:27 | postmaster segfault with tsearch2? |