Re: Help tuning postgres
От | Andrew Sullivan |
---|---|
Тема | Re: Help tuning postgres |
Дата | |
Msg-id | 20051012220036.GE13571@phlogiston.dyndns.org обсуждение исходный текст |
Ответ на | Re: Help tuning postgres (Csaba Nagy <nagy@ecircle-ag.com>) |
Ответы |
Re: Help tuning postgres
|
Список | pgsql-performance |
On Wed, Oct 12, 2005 at 06:55:30PM +0200, Csaba Nagy wrote: > Ok, that was the first thing I've done, checking out the explain of the > query. I don't really need the analyze part, as the plan is going for > the index, which is the right decision. The updates are simple one-row How do you know? You _do_ need the ANALYSE, because it'll tell you what the query _actually did_ as opposed to what the planner thought it was going to do. Note that EXPLAIN ANALYSE actually performs the work, so you better do it in a transaction and ROLLBACK if it's a production system. > Actually I've done an iostat run in the meantime (just learned how to > use it), and looks like the disk is 100 saturated. So it clearly is a > disk issue in this case. And it turns out the Oracle hardware has an Yes, but it could be a disk issue because you're doing more work than you need to. If your UPDATEs are chasing down a lot of dead tuples, for instance, you'll peg your I/O even though you ought to have I/O to burn. A -- Andrew Sullivan | ajs@crankycanuck.ca The whole tendency of modern prose is away from concreteness. --George Orwell
В списке pgsql-performance по дате отправления: