Jan Wieck wrote:
On 8/9/2004 7:41 PM, Gaetano Mendola wrote:
If I remember well this is the first command that need to change
GUC in order to change behaviour, I don't think we wrote:
set vacuum_mode = full;
set vacuum_verbosity = on;
vacuum;
You got a point here. However, we don't have
SELECT
On 8/9/2004 7:41 PM, Gaetano Mendola wrote:
If I remember well this is the first command that need to change
GUC in order to change behaviour, I don't think we wrote:
set vacuum_mode = full;
set vacuum_verbosity = on;
vacuum;
You got a point here. However, we don't have
SELECT foo FROM bar WHER
Gaetano Mendola wrote:
> However I think is annoying to write:
>
> set vacuum_cost_delay = 100;
> vacuum table ;
> set vacuum_cost_delay = 0;
> set ;
> vacuum table ;
>
>
Well, you are already seting it to zero for night, so why not just set
it to non-zero for day? Seems the same to me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jan Wieck wrote:
| On 8/9/2004 1:19 PM, Gaetano Mendola wrote:
|
|> Jan Wieck wrote:
|>
|>> On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
|>>
|>>> Hi all,
|>>> I have seen the big debat about to have the delay
|>>> off or on by default.
|>>>
|>>> Why not
On 8/9/2004 1:19 PM, Gaetano Mendola wrote:
Jan Wieck wrote:
On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alvaro Herrera wrote:
| On Mon, Aug 09, 2004 at 07:19:44PM +0200, Gaetano Mendola wrote:
|
|
|>So the other parameter will inserted in the new sintax too, I think is
|>fundamental
|>the ability of override this values during the vacuum call:
|>
|>VACUUM
On Mon, Aug 09, 2004 at 07:19:44PM +0200, Gaetano Mendola wrote:
> So the other parameter will inserted in the new sintax too, I think is
> fundamental
> the ability of override this values during the vacuum call:
>
> VACUUM WITH DELAY 100 [ ];
What's wrong with
SET vacuum_delat 100;
Jan Wieck wrote:
On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM WITH DELAY 100;
It's not just one parameter
On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM WITH DELAY 100;
It's not just one parameter to tune here. It
On Mon, 2004-08-09 at 05:19, Gaetano Mendola wrote:
> Hi all,
> I have seen the big debat about to have the delay
> off or on by default.
>
> Why not enable it by default and introduce a new
> parameter to vacuum command itself ? Something like:
>
>
> VACUUM WITH DELAY 100;
>
>
> this wil
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM WITH DELAY 100;
this will permit to change easilly the delay in the maintainance
scripts.
Regards
Gaetan
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Bruce Momjian) would write:
> I guess my question is that now that we have the new cache
> replacement policy, is the vacuum delay worth while. I looked at
> http://developer.postgresql.org/~wieck/vacuum_cost/ and does seem
> useful.
They
Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> Attached is a corrected version that solves the query cancel problem by
> >> not napping any more and going full speed as soon as any signal is
> >> pending. If nobody objects, I'm going to commit this tomorrow.
> >
> > Jan, th
Jan Wieck wrote:
> Attached is a corrected version that solves the query cancel problem by
> not napping any more and going full speed as soon as any signal is
> pending. If nobody objects, I'm going to commit this tomorrow.
Jan, three questions. First, is this useful now that we have the new
c
Bruce Momjian wrote:
Jan Wieck wrote:
Attached is a corrected version that solves the query cancel problem by
not napping any more and going full speed as soon as any signal is
pending. If nobody objects, I'm going to commit this tomorrow.
Jan, three questions. First, is this useful now that we
Attached is a corrected version that solves the query cancel problem by
not napping any more and going full speed as soon as any signal is
pending. If nobody objects, I'm going to commit this tomorrow.
Jan
Jan Wieck wrote:
The attached patch applies to CVS tip as of 02/05/2004 and implements
The attached patch applies to CVS tip as of 02/05/2004 and implements
the cost based vacuum delay feature.
A detailed description with charts of different configuration settings
can be found here:
http://developer.postgresql.org/~wieck/vacuum_cost/
There is a problem left that seems to be
Josh Berkus wrote:
People,
I don't have the time to make enough different attempts to find the one
that pleases all. My argument still is that all this IO throttling and
IO optimizing is mainly needed for dedicated servers, because I think
that if you still run multiple services on one box you
On Mon, 2004-01-19 at 08:37, Jan Wieck wrote:
> but I will not waste my time with making patches nobody even gives a try.
I downloaded and tested your patches. I just didn't get results get
results that were put together well enough to present to the group. I
hope this doesn't fall by the waysi
People,
> I don't have the time to make enough different attempts to find the one
> that pleases all. My argument still is that all this IO throttling and
> IO optimizing is mainly needed for dedicated servers, because I think
> that if you still run multiple services on one box you're not real
Stephen wrote:
The vacuum delay patch is not the ideal solution but it worked like a charm
on my servers. I really need the vacuum delay patch or a better solution in
7.5. I'm getting millions of requests a month and running VACUUM without the
patch makes PostgreSQL useless for many consecutive ho
The vacuum delay patch is not the ideal solution but it worked like a charm
on my servers. I really need the vacuum delay patch or a better solution in
7.5. I'm getting millions of requests a month and running VACUUM without the
patch makes PostgreSQL useless for many consecutive hours. Not quite t
22 matches
Mail list logo
