Steve Crawford wrote:
On Monday 21 March 2005 11:40 am, Tom Lane wrote:
"Matthew T. O'Connor" writes:
I believe this discrepancy has to do with the fact that ANALYZE
can return some very bogus values for reltuples, where as vacuum
always returns an accurate count. I'm not sure how to best
On Monday 21 March 2005 11:40 am, Tom Lane wrote:
> "Matthew T. O'Connor" writes:
> > I believe this discrepancy has to do with the fact that ANALYZE
> > can return some very bogus values for reltuples, where as vacuum
> > always returns an accurate count. I'm not sure how to best
> > handle this
Steve Crawford <[EMAIL PROTECTED]> writes:
> Just to make sure I'm understanding things correctly this time...I
> originally (mis)understood these as settings related to resources
> used _during_ vacuuming. My current understanding is that they are
> basically pointers that track what space is a
On Monday 21 March 2005 11:40 am, Tom Lane wrote:
> However, given that there are 9334 tuples in 82282 pages, I'd say
> that autovacuum has already failed Steve rather badly :-(. There
> shouldn't be more than a couple hundred pages given that number of
> rows. Perhaps the FSM settings are too s
"Matthew T. O'Connor" writes:
> I believe this discrepancy has to do with the fact that ANALYZE can
> return some very bogus values for reltuples, where as vacuum always
> returns an accurate count. I'm not sure how to best handle this.
I think 8.0's ANALYZE will do a better estimation job ...
Tom Lane wrote:
Steve Crawford <[EMAIL PROTECTED]> writes:
pg_autovacuum is from 7.4.6 release and is showing periodic vacuums of
the problem tables. I thought that bug was in some release prior to
7.4.6. Does the bug allow it to show a vacuum taking place but not do
it?
I don't recall t
Steve Crawford wrote:
On Thursday 17 March 2005 3:15 pm, Steve Crawford wrote:
I'm having trouble with physical growth of postgresql system
tables
Additional info. The most recent autovacuum entries for the
pg_attribute table are:
[2005...] Performing: VACUUM ANALYZE "pg_catalog"."pg
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Steve Crawford)
belched out:
> On Thursday 17 March 2005 3:51 pm, Tom Lane wrote:
>> Steve Crawford <[EMAIL PROTECTED]> writes:
>> > My autovacuum config is running and I do see regular periodic
>> > vacuums of these pg_ tables but still
Steve Crawford <[EMAIL PROTECTED]> writes:
> On Thursday 17 March 2005 3:51 pm, Tom Lane wrote:
>> Do you have the FSM settings set large enough to account for all
>> the free space?
> max_fsm_pages = 2
> max_fsm_relations = 1000
That doesn't sound like nearly enough pages for a 2G database.
On Thursday 17 March 2005 3:51 pm, Tom Lane wrote:
> Steve Crawford <[EMAIL PROTECTED]> writes:
> > My autovacuum config is running and I do see regular periodic
> > vacuums of these pg_ tables but still they grow.
>
> Do you have the FSM settings set large enough to account for all
> the free spac
Steve Crawford <[EMAIL PROTECTED]> writes:
> My autovacuum config is running and I do see regular periodic vacuums
> of these pg_ tables but still they grow.
Do you have the FSM settings set large enough to account for all the
free space?
Also you might want to check for newer versions of autova
On Thursday 17 March 2005 3:15 pm, Steve Crawford wrote:
> I'm having trouble with physical growth of postgresql system
> tables
Additional info. The most recent autovacuum entries for the
pg_attribute table are:
[2005...] Performing: VACUUM ANALYZE "pg_catalog"."pg_attribute"
[2005...] t
I'm having trouble with physical growth of postgresql system tables.
Server is 7.4.6 and there are several databases in the cluster. The
autovacuum daemon has been running since the data was restored after
an upgrade a few months ago. Unfortunately my system tables are
taking an unreasonable am
13 matches
Mail list logo
