(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 figu
On Mon, Jun 8, 2009 at 10:40 AM, Alvaro
Herrera wrote:
> Tom Lane escribió:
>> Alvaro Herrera 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
Tom Lane escribió:
> Alvaro Herrera 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 from the docs,
Alvaro Herrera 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
--
Sent via pgsql-hackers
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
Robert Haas 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 clear problem, we can
On Sun, Jun 7, 2009 at 4:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 7, 2009 at 3:24 PM, Tom Lane 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 page
Robert Haas writes:
> On Sun, Jun 7, 2009 at 3:24 PM, Tom Lane 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 should be a
>> considerably less b
On Sun, Jun 7, 2009 at 3:24 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 reasonable estimate of
On Sun, Jun 7, 2009 at 7:11 PM, Robert Haas 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 scan the entire heap
On Sat, Jun 6, 2009 at 3:44 PM, Tom Lane 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 confirmed my prio
Simon Riggs 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.
regards, tom lane
On Sat, 2009-06-06 at 15:44 -0400, Tom Lane wrote:
> I think probably the only workable solution for 8.4 is to use the prior
> value of the relation's reltuples field as num_heap_tuples when we have
> not scanned the whole heap. This will effectively mean that index
> reltuples values don't chan
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 f
> 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 r
(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
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
18 matches
Mail list logo
