| From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
|---|---|
| To: | Rob Nagler <nagler(at)bivio(dot)biz> |
| Cc: | <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: vacuum locking |
| Date: | 2003-10-30 17:05:15 |
| Message-ID: | Pine.LNX.4.33.0310301004170.23412-100000@css120.ihs.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, 30 Oct 2003, Rob Nagler wrote:
> The vacuum problem is very serious for the problematic database to the
> point that one of my customer's customers said:
>
> However, I am having a hard time understanding why the system is so
> slow... from my perspective it seems like you have some fundamental
> database issues that need to be addressed.
>
> This is simply unacceptable, and that's why we're moving to Oracle.
> It's very bad for my business reputation.
>
> I don't have a ready solution to vacuuming, and none on the list have
> been effective. We'll be adding more memory, but it seems to be disk
> bandwidth problem. I run Oracle on much slower system, and I've never
> noticed problems of this kind, even when a database-wide validation is
> running. When vacuum is running, it's going through the entire
> database, and that pretty much trashes all other queries, especially
> DSS queries. As always it is just software, and there's got to be
> 80/20 solution.
Have you looked at the autovacuum daemon? Was it found wanting or what?
I've had good luck with it so far, so I was just wondering if it might
work for your needs as well. It's quite intelligent about which tables
et.al. it vacuums.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | CLeon | 2003-10-30 17:28:10 | Re: [linux-lvm] RE: [PERFORM] backup/restore - another |
| Previous Message | Rob Nagler | 2003-10-30 17:04:24 | Re: vacuum locking |