Re: [HACKERS] Autovacuum Improvements - Mailing list pgsql-general

From Kenneth Marshall
Subject Re: [HACKERS] Autovacuum Improvements
Date
Msg-id 20070122193028.GD7746@it.is.rice.edu
Whole thread Raw
In response to Re: [HACKERS] Autovacuum Improvements  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-general
On Mon, Jan 22, 2007 at 07:24:20PM +0000, Heikki Linnakangas wrote:
> Kenneth Marshall wrote:
> >On Mon, Jan 22, 2007 at 06:42:09PM +0000, Simon Riggs wrote:
> >>Hold that thought! Read Heikki's Piggyback VACUUM idea on new thread...
> >
> >There may be other functions that could leverage a similar sort of
> >infrastructure. For example, a long DB mining query could be registered
> >with the system. Then as the pieces of the table/database are brought in
> >to shared memory during the normal daily DB activity they can be acquired
> >without forcing the DB to run a very I/O expensive query when waiting a
> >bit for the results would be acceptable. As long as we are thinking
> >piggyback.
>
> Yeah, I had the same idea when we discussed synchronizing sequential
> scans. The biggest difference is that with queries, there's often a user
> waiting for the query to finish, but with vacuum we don't care so much
> how long it takes.
>
Yes, but with trending and statistical analysis you may not need the
exact answer ASAP. An approximate answer based on a fraction of the
information would be useful. Also, "what if" queries could be run without
impacting the production uses of a database. One might imagine having a
query with results that "converge" as the table is processed during normal
use.

Ken

pgsql-general by date:

Previous
From: Kenneth Marshall
Date:
Subject: Re: [HACKERS] Autovacuum Improvements
Next
From: Paul Lambert
Date:
Subject: Re: Installing Postegres side-by-side with M$ SQL server