| From: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
| Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, "Ron Mayer" <rm_pg(at)cheapcomplexdevices(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com> |
| Subject: | Re: autovacuum next steps, take 2 |
| Date: | 2007-02-22 19:35:17 |
| Message-ID: | E1539E0ED7043848906A8FF995BDA57901CAF73A@m0143.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > > vacuum should be a process with the least amount of voodoo.
> > > If we can just have vacuum_delay and vacuum_threshold, where
> > > threshold allows an arbitrary setting of how much bandwidth we
will
> > > allot to the process, then that is a beyond wonderful thing.
> > >
> > > It is easy to determine how much IO you have, and what
> you can spare.
> >
> > The tricky part is what metric to use. Imho "IO per second"
> would be
> > good.
> > In a typical DB scenario that is the IO bottleneck, not the Mb/s.
>
> Well, right now they're one in the same... but yeah, IO/sec
> probably does make more sense.
Hopefully not :-) Else you have no readahead. And that is imho the
problem.
You need to anticipate how many physical IO's your logical IO's cause.
And this is near impossible unless we group IO's in pg itself.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2007-02-22 19:36:18 | Re: Log levels for checkpoint/bgwriter monitoring |
| Previous Message | Zeugswetter Andreas ADI SD | 2007-02-22 19:25:22 | Re: Column storage positions |