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
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 will permit to
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
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
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;
SET
-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 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
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 enable it by default
Gaetano Mendola wrote:
However I think is annoying to write:
set vacuum_cost_delay = 100;
vacuum table big_huge;
set vacuum_cost_delay = 0;
set whatelse;
vacuum table night_table;
Well, you are already seting it to zero for night, so why not just set
it to non-zero for day?
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
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
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
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
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, three questions.
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
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
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
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 really
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
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
20 matches
Mail list logo
