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 r
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 du
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 ther
"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 b
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
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 require
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
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
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 operati
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
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, http://www.Enterp
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 deta
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? T
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
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 p
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
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 c
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 it'
18 matches
Mail list logo
