| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
| Cc: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Suggestion; "WITH VACUUM" option |
| Date: | 2002-12-17 01:16:27 |
| Message-ID: | 2699.1040087787@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> writes:
> Oh, yeah I have no doubt of that. I was thinking more along the lines of
> when a transaction ends it throws a background "vacuum table1;vacuum
> table2;vacuum tablen" command into some kind of vacuuming hopper.
Actually, the plans I liked best for driving auto-vacuum were
essentially an indirect version of that: the FSM module would keep track
of committed deletes + aborted inserts for each active table, and then
the autovacuum scheduler could use that info to decide which tables are
highest-priority to vacuum.
(Or possibly the runtime stats module would be a better place to track
it than FSM.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2002-12-17 02:07:55 | Password security question |
| Previous Message | Magnus Naeslund(f) | 2002-12-17 01:00:47 | Re: [HACKERS] following instructions GCC |