(back from vacation)
Tom Lane wrote:
I wrote:
Another interesting question is why successive vacuums aren't causing
the index reltuples counts to go to zero. Shouldn't a partial vacuum
result in *all* pages of the relation being marked as not needing to
be examined by the next vacuum?
I
Robert Haas escribió:
Basically, I'm trying to figure out what we're going to recommend to
someone who gets bitten by whatever remaining corner case still exists
after your recent patch, and I admit I'm not real clear on what that
is. VACUUM FULL doesn't seem like a good solution because
Alvaro Herrera alvhe...@commandprompt.com writes:
Robert Haas escribió:
Maybe we should just have a GUC to enable/disable
partial vacuums.
IIRC you can set vacuum_freeze_table_age to 0.
That has the same effects as issuing VACUUM FREEZE, no?
regards, tom lane
--
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Robert Haas escribi�:
Maybe we should just have a GUC to enable/disable
partial vacuums.
IIRC you can set vacuum_freeze_table_age to 0.
That has the same effects as issuing VACUUM FREEZE, no?
As far as I can make
On Mon, Jun 8, 2009 at 10:40 AM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Robert Haas escribió:
Maybe we should just have a GUC to enable/disable
partial vacuums.
IIRC you can set vacuum_freeze_table_age to 0.
Simon Riggs si...@2ndquadrant.com writes:
On Sat, 2009-06-06 at 15:44 -0400, Tom Lane wrote:
In the longer term, we need to do something else.
-1 for such radical change at this stage of release.
Uh, by longer term I meant this is something to think about for 8.5.
On Sat, Jun 6, 2009 at 3:44 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I complained a couple days ago that in HEAD, vacuum is putting
very bogus values into pg_class.reltuples for indexes:
http://archives.postgresql.org/pgsql-bugs/2009-06/msg00037.php
After looking through the code a bit, I've
On Sun, Jun 7, 2009 at 7:11 PM, Robert Haasrobertmh...@gmail.com wrote:
Am I wrong to be frightened by the implications of updating this value
only once in a blue moon? Doesn't this have the potential to result
in really bad plans? Do we have any reasonable manual way of forcing
VACUUM to
Robert Haas robertmh...@gmail.com writes:
Am I wrong to be frightened by the implications of updating this value
only once in a blue moon?
It's not great, but I think it's probably not catastrophic either.
Keep in mind that all we need from reltuples is that the ratio
reltuples/relpages be a
On Sun, Jun 7, 2009 at 3:24 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Am I wrong to be frightened by the implications of updating this value
only once in a blue moon?
It's not great, but I think it's probably not catastrophic either.
Keep in mind that
Robert Haas robertmh...@gmail.com writes:
On Sun, Jun 7, 2009 at 3:24 PM, Tom Lanet...@sss.pgh.pa.us wrote:
[ thinks a bit and reads the code some more ... ] There is a
considerably safer alternative, which is to let ANALYZE update the
reltuples estimate based on the pages it sampled; which
On Sun, Jun 7, 2009 at 4:19 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jun 7, 2009 at 3:24 PM, Tom Lanet...@sss.pgh.pa.us wrote:
[ thinks a bit and reads the code some more ... ] There is a
considerably safer alternative, which is to let ANALYZE
Robert Haas robertmh...@gmail.com writes:
Basically, I'm trying to figure out what we're going to recommend to
someone who gets bitten by whatever remaining corner case still exists
after your recent patch, and I admit I'm not real clear on what that
is.
If anyone actually shows up with a
I complained a couple days ago that in HEAD, vacuum is putting
very bogus values into pg_class.reltuples for indexes:
http://archives.postgresql.org/pgsql-bugs/2009-06/msg00037.php
After looking through the code a bit, I've confirmed my prior guess that
this is caused by the partial-vacuum patch.
I wrote:
Another interesting question is why successive vacuums aren't causing
the index reltuples counts to go to zero. Shouldn't a partial vacuum
result in *all* pages of the relation being marked as not needing to
be examined by the next vacuum?
I figured out the reason for that: the
Hi all,
(B
(BI'm thinking about "partial (or range) vacuum" feature.
(B
(BAs you know, vacuum process scans and re-organizes a whole table,
(Bso huge cpu load will be generated when vacuuming a large table,
(Band it will take long time (in some cases, it may take 10 minutes
(Bor more).
(B
Satoshi Nagayasu [EMAIL PROTECTED] writes:
Attached patch extends vacuum syntax and lazy_scan_heap() function.
Backend can process the partial vacuum command as below:
psql$ vacuum table1 (0, 100);
In the above command, 0 means start block number,
and 100 means end block number of the
(BTom Lane wrote:
(B I think the major problem with this is the (untenable) assumption that
(B the user is keeping track of the table size accurately. It'd be very
(B likely that portions of the table get missed if someone tries to
(B maintain a table using only partial vacuums specified in
Have you looked at the vacuum cost delay features present in 8.0?
On the whole that seems like a better solution for reducing the impact
of routine vacuuming than trying to manage partial vacuuming with an
approach like this.
IMO vacuum cost delay seems not to be a solution. To keep long
19 matches
Mail list logo
