From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Vacuum questions... |
Date: | 2005-09-28 00:22:03 |
Message-ID: | 20050928002203.GF30974@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 27, 2005 at 07:12:21PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> > AFAIK, this should allow both to run in seperate transactions.
>
> ... and pretty much destroy any synchronization between the two scans,
> which was sort of the point wasn't it?
Aren't there ways to sync them outside of a transaction? My theory is
that you don't need to syncronize them at the tuple level, since
whichever one gets ahead reading the HEAP will be pulling the data off
the drive, while the one that's behind will just grab it out of the
buffer (or at worst, the kernel's cache). So all you should need to do
is start both scans at about (as in within a few seconds) the same time.
Heck, if vacuum was made to put more verbose info in it's process status
then it could be as simple as having pg_dump start a vacuum of a table
in a seperate connection and just watching for the status to indicate it
had started vacuuming the table.
I *think* this shouldn't be too hard to test, which is good since it's
all theory right now. :)
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-09-28 01:58:01 | Re: Open items list for 8.1 |
Previous Message | Jim C. Nasby | 2005-09-28 00:16:28 | Re: \d on database with a lot of tables is slow |