Re: [PERFORM] How to fast the REINDEX

2010-04-06 Thread Hannu Krosing
On Thu, 2010-04-01 at 04:27 +0530, raghavendra t wrote: I'm sorry I couldn't come up with more, but what you've provided so far is roughly equivalent to me telling you that it takes over four hours to travel to see my Uncle Jim, and then asking you how

Re: [PERFORM] How to fast the REINDEX

2010-04-05 Thread Robert Haas
On Thu, Apr 1, 2010 at 9:47 AM, raghavendra t raagavendra@gmail.com wrote: and deletes. We also has the weekly maintance of VACUUM, but still reindex takes lot of time. If you only VACUUM once a week, *everything* is going to take a lot of time. ...Robert -- Sent via pgsql-performance

Re: [PERFORM] How to fast the REINDEX

2010-04-01 Thread Steve Clark
On 03/31/2010 11:11 PM, Craig Ringer wrote: Jaime Casanova wrote: On Wed, Mar 31, 2010 at 5:33 PM, raghavendra t raagavendra@gmail.com wrote: Why are you doing that? Our table face lot of updates and deletes in a day, so we prefer reindex to update the indexes as well overcome with a

Re: [PERFORM] How to fast the REINDEX

2010-04-01 Thread Greg Smith
raghavendra t wrote: 1. What are the parameters will effect, when issuing the REINDEX command 2. Best possible way to increase the spead of the REINDEX If you haven't done the usual general tuning on your server, that might help. http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

Re: [PERFORM] How to fast the REINDEX

2010-04-01 Thread Pierre C
So am I to understand I don't need to do daily reindexing as a maintenance measure with 8.3.7 on FreeBSD. Sometimes it's better to have indexes with some space in them so every insert doesn't hit a full index page and triggers a page split to make some space. Of course if the index is

Re: [PERFORM] How to fast the REINDEX

2010-04-01 Thread raghavendra t
Hi All, System Config - CPU - Intel® Xenon® CPU CPU Speed - 3.16 GHz Server Model - Sun Fire X4150 RAM-Size - 16GB Steve: So am I to understand I don't need to do daily reindexing as a maintenance measure with 8.3.7 on FreeBSD. My question is something like Steve's, why

Re: [PERFORM] How to fast the REINDEX

2010-04-01 Thread Brad Nicholson
On Thu, 2010-04-01 at 19:17 +0530, raghavendra t wrote: Hi All, System Config - CPU - Intel® Xenon® CPU CPU Speed - 3.16 GHz Server Model - Sun Fire X4150 RAM-Size - 16GB Steve: So am I to understand I don't need to do daily reindexing as a

Re: [PERFORM] How to fast the REINDEX

2010-04-01 Thread Kevin Grittner
raghavendra t raagavendra@gmail.com wrote: System Config - CPU - Intel* Xenon* CPU CPU Speed - 3.16 GHz Server Model - Sun Fire X4150 RAM-Size - 16GB The disk system matters a lot, too. How many drives do you have in what RAID configuration(s)? My question is

Re: [PERFORM] How to fast the REINDEX

2010-03-31 Thread Kevin Grittner
raghavendra t raagavendra@gmail.com wrote: I have a table with 40GB size, it has few indexes on it. What does the table look like? What indexes are there? When i try to REINDEX on the table, Why are you doing that? its take a long time. How long? I tried increasing the

Re: [PERFORM] How to fast the REINDEX

2010-03-31 Thread raghavendra t
Hi Kevin, Thank you for the update, What does the table look like? What indexes are there? Table has a combination of byteas. Indexes are b-tree and Partial Why are you doing that? Our table face lot of updates and deletes in a day, so we prefer reindex to update the indexes as well overcome

Re: [PERFORM] How to fast the REINDEX

2010-03-31 Thread Kevin Grittner
raghavendra t raagavendra@gmail.com wrote: overcome with a corrupted index. If this is a one-time fix for a corrupted index, did you look at CREATE INDEX CONCURRENTLY? You could avoid any down time while you fix things up.

Re: [PERFORM] How to fast the REINDEX

2010-03-31 Thread raghavendra t
If this is a one-time fix for a corrupted index, did you look at CREATE INDEX CONCURRENTLY? You could avoid any down time while you fix things up. Using CREATE INDEX CONCURRENTLY will avoid the exclusive locks on the table, but my question is, how to get a performance on the existing

Re: [PERFORM] How to fast the REINDEX

2010-03-31 Thread Kevin Grittner
raghavendra t raagavendra@gmail.com wrote: my question is, how to get a performance on the existing indexes. You mean to say , drop the existing indexes and create the index with CONCURRENTLY. Does this give the performance back. You would normally want to create first and then drop the

Re: [PERFORM] How to fast the REINDEX

2010-03-31 Thread raghavendra t
Thank you for the suggestion. On Thu, Apr 1, 2010 at 3:21 AM, Kevin Grittner kevin.gritt...@wicourts.govwrote: raghavendra t raagavendra@gmail.com wrote: my question is, how to get a performance on the existing indexes. You mean to say , drop the existing indexes and create the index

Re: [PERFORM] How to fast the REINDEX

2010-03-31 Thread Kevin Grittner
raghavendra t raagavendra@gmail.com wrote: Thank you for the suggestion. I'm sorry I couldn't come up with more, but what you've provided so far is roughly equivalent to me telling you that it takes over four hours to travel to see my Uncle Jim, and then asking you how I can find out how

Re: [PERFORM] How to fast the REINDEX

2010-03-31 Thread Jaime Casanova
On Wed, Mar 31, 2010 at 5:33 PM, raghavendra t raagavendra@gmail.com wrote: Why are you doing that? Our table face lot of updates and deletes in a day, so we prefer reindex to update the indexes as well overcome with a corrupted index. do you have a corrupted index? if not, there is

Re: [PERFORM] How to fast the REINDEX

2010-03-31 Thread raghavendra t
I'm sorry I couldn't come up with more, but what you've provided so far is roughly equivalent to me telling you that it takes over four hours to travel to see my Uncle Jim, and then asking you how I can find out how he's doing in less time than that. There's just not much to go on. :-(

Re: [PERFORM] How to fast the REINDEX

2010-03-31 Thread Craig Ringer
Jaime Casanova wrote: On Wed, Mar 31, 2010 at 5:33 PM, raghavendra t raagavendra@gmail.com wrote: Why are you doing that? Our table face lot of updates and deletes in a day, so we prefer reindex to update the indexes as well overcome with a corrupted index. do you have a corrupted