Re: [HACKERS] Vacuum questions...

2005-09-30 Thread Jim C. Nasby
On Thu, Sep 29, 2005 at 12:50:13AM +0300, Hannu Krosing wrote: On T, 2005-09-27 at 17:57 -0500, Jim C. Nasby wrote: On Tue, Sep 27, 2005 at 02:47:46PM -0400, Jan Wieck wrote: On 9/24/2005 8:17 PM, Jim C. Nasby wrote: Would it be difficult to vacuum as part of a dump? The reasoning

Re: [HACKERS] Vacuum questions...

2005-09-28 Thread Hannu Krosing
On T, 2005-09-27 at 17:57 -0500, Jim C. Nasby wrote: On Tue, Sep 27, 2005 at 02:47:46PM -0400, Jan Wieck wrote: On 9/24/2005 8:17 PM, Jim C. Nasby wrote: Would it be difficult to vacuum as part of a dump? The reasoning behind this is that you have to read the table to do the dump anyway,

Re: [HACKERS] Vacuum questions...

2005-09-27 Thread Gaetano Mendola
Gaetano Mendola wrote: Alvaro Herrera wrote: On Mon, Sep 26, 2005 at 05:41:24PM +0200, Gaetano Mendola wrote: Joshua D. Drake wrote: Autovacuum is integrated into the backend for 8.1 Can I set the autovacuum parameter per table instead of per engine ? Yes. Reading the 8.1 release note I

Re: [HACKERS] Vacuum questions...

2005-09-27 Thread Jan Wieck
On 9/24/2005 8:17 PM, Jim C. Nasby wrote: Would it be difficult to vacuum as part of a dump? The reasoning behind this is that you have to read the table to do the dump anyway, I think aside from what's been said so far, it would be rather difficult anyway. pg_dump relies on MVCC and

Re: [HACKERS] Vacuum questions...

2005-09-27 Thread Jim C. Nasby
On Tue, Sep 27, 2005 at 02:47:46PM -0400, Jan Wieck wrote: On 9/24/2005 8:17 PM, Jim C. Nasby wrote: Would it be difficult to vacuum as part of a dump? The reasoning behind this is that you have to read the table to do the dump anyway, I think aside from what's been said so far, it would

Re: [HACKERS] Vacuum questions...

2005-09-27 Thread Tom Lane
Jim C. Nasby [EMAIL PROTECTED] 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? regards, tom lane ---(end of

Re: [HACKERS] Vacuum questions...

2005-09-27 Thread Jim C. Nasby
On Tue, Sep 27, 2005 at 07:12:21PM -0400, Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] 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

Re: [HACKERS] Vacuum questions...

2005-09-26 Thread Gaetano Mendola
Joshua D. Drake wrote: Hannu Krosing wrote: On L, 2005-09-24 at 20:25 -0700, Joshua D. Drake wrote: Actually this also probably would not gain you much in 8.1 as vacuum in theory is already dealing with itself. Interesting. Could you explain it in a more detailed way ? How does

Re: [HACKERS] Vacuum questions...

2005-09-26 Thread Alvaro Herrera
On Mon, Sep 26, 2005 at 05:41:24PM +0200, Gaetano Mendola wrote: Joshua D. Drake wrote: Autovacuum is integrated into the backend for 8.1 Can I set the autovacuum parameter per table instead of per engine ? Yes. -- Alvaro Herrera Architect,

Re: [HACKERS] Vacuum questions...

2005-09-26 Thread Jim C. Nasby
On Sun, Sep 25, 2005 at 11:50:14AM -0400, Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: Perhaps VACUUM could send some statistics after each N pages and this would then be available through something similar to pg_statistics table. Why not just have it send some text to be

Re: [HACKERS] Vacuum questions...

2005-09-26 Thread Jim C. Nasby
On Sat, Sep 24, 2005 at 08:25:30PM -0700, Joshua D. Drake wrote: Jim C. Nasby wrote: Would it be difficult to vacuum as part of a dump? The reasoning behind this is that you have to read the table to do the dump anyway, so it would be a good time to be able to piggy-back other operations

Re: [HACKERS] Vacuum questions...

2005-09-26 Thread Gaetano Mendola
Alvaro Herrera wrote: On Mon, Sep 26, 2005 at 05:41:24PM +0200, Gaetano Mendola wrote: Joshua D. Drake wrote: Autovacuum is integrated into the backend for 8.1 Can I set the autovacuum parameter per table instead of per engine ? Yes. Finally :-) good work. Regards Gaetano Mendola

Re: [HACKERS] Vacuum questions...

2005-09-25 Thread Hannu Krosing
On L, 2005-09-24 at 20:25 -0700, Joshua D. Drake wrote: Actually this also probably would not gain you much in 8.1 as vacuum in theory is already dealing with itself. Interesting. Could you explain it in a more detailed way ? How does vacuum deal with itself in 8.1 ? Also, would it be

Re: [HACKERS] Vacuum questions...

2005-09-25 Thread Joshua D. Drake
Hannu Krosing wrote: On L, 2005-09-24 at 20:25 -0700, Joshua D. Drake wrote: Actually this also probably would not gain you much in 8.1 as vacuum in theory is already dealing with itself. Interesting. Could you explain it in a more detailed way ? How does vacuum deal with itself in

Re: [HACKERS] Vacuum questions...

2005-09-25 Thread Tom Lane
Hannu Krosing [EMAIL PROTECTED] writes: Perhaps VACUUM could send some statistics after each N pages and this would then be available through something similar to pg_statistics table. Why not just have it send some text to be displayed in the current command field of pg_stat_activity? The

[HACKERS] Vacuum questions...

2005-09-24 Thread Jim C. Nasby
Would it be difficult to vacuum as part of a dump? The reasoning behind this is that you have to read the table to do the dump anyway, so it would be a good time to be able to piggy-back other operations that need to read the entire table on top. I know vacuuming of indexes complicates this, so

Re: [HACKERS] Vacuum questions...

2005-09-24 Thread Joshua D. Drake
Jim C. Nasby wrote: Would it be difficult to vacuum as part of a dump? The reasoning behind this is that you have to read the table to do the dump anyway, so it would be a good time to be able to piggy-back other operations that need to read the entire table on top. I know vacuuming of indexes

Re: [HACKERS] Vacuum questions...

2005-09-24 Thread Alvaro Herrera
On Sat, Sep 24, 2005 at 07:17:38PM -0500, Jim C. Nasby wrote: Finally, if vacuum_delay is enabled, does vacuum_cost_page_miss consider a miss as not in the database buffer, or not in the kernel buffer? The database buffer. I remember discussions about trying to track IO request times to try