| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Ron St-Pierre <rstpierre(at)syscor(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Index Problem? |
| Date: | 2004-04-16 17:01:52 |
| Message-ID: | 200404161001.52989.josh@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Ron,
> The emp table has 60 columns, all indexed, about two-thirds are numeric,
> but they are not affected by this update. The other 50+ columns are
> updated in the middle of the night and the amount of time that update
> takes isn't a concern.
Well, I'd say that you have an application design problem, but that's not what
you asked for help with ;-)
> Late last night I dumped the table, dropped it and re-created it from
> the dump (on the production server - when no one was looking). When I
> re-ran the function it took almost 11 minutes, which was pretty much in
> line with my results from the dev server.
Sounds like you need to run a REINDEX on the table -- and after that,
dramatically increase your max_fsm_pages, and run lazy VACUUM immediately
after the batch update to clean up.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-04-16 17:04:58 | Re: Horribly slow hash join |
| Previous Message | Josh Berkus | 2004-04-16 16:58:14 | Re: RESOLVED: Re: Wierd context-switching issue on Xeon |