Our pgstats.stat file is 40M for 8.2, on 8.1 it was 33M. Our schema size
hasn't grown *that* much in the two weeks since we upgraded
I'm not sure if this sheds any more light on the situation, but in
scanning down through the process output from truss, it looks like the
first section of output
I wrote:
> What I think we need to do about this is
> (1) fix pgstat_vacuum_tabstats to have non-O(N^2) behavior; I'm thinking
> of using a hash table for the OIDs instead of a linear list. Should be
> a pretty small change; I'll work on it today.
I've applied the attached patch to 8.2 to do the
I wrote:
> (2) Reconsider whether last-vacuum-time should be sent to the collector
> unconditionally.
Actually, now that I look, the collector already contains this logic:
/*
* Don't create either the database or table entry if it doesn't already
* exist. This avoids bloating the s
For 8.1, we did have stats_block_level and stats_row_level on, so thats
not it either :-/ However, I did go on to an alternate database of ours
on the same machine, using the same install, same postmaster - that
holds primarily static relations, and not many of those (16 relations
total). The r
On Thu, Jan 11, 2007 at 04:49:28PM -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > What I think we need to do about this is
> >
> > (1) fix pgstat_vacuum_tabstats to have non-O(N^2) behavior; I'm thinking
> > of using a hash table for the OIDs instead of a linear list. Should be
> > a prett
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> It's not clear to me how this fix will alter the INSERT issue Kim
> mentions.
I didn't say that it would; we have no information on the INSERT issue,
so I'm just concentrating on the problem that he did provide info on.
(BTW, I suppose the slow-\d issue
On Thu, 2007-01-11 at 14:45 -0500, Tom Lane wrote:
> Kim <[EMAIL PROTECTED]> writes:
> > We were running on 8.1.1 previous to upgrading to 8.2, and yes, we
> > definitely have a heafty pg_class. The inheritance model is heavily used
> > in our schema (the results of the group by you wanted to see
Tom Lane wrote:
> What I think we need to do about this is
>
> (1) fix pgstat_vacuum_tabstats to have non-O(N^2) behavior; I'm thinking
> of using a hash table for the OIDs instead of a linear list. Should be
> a pretty small change; I'll work on it today.
>
> (2) Reconsider whether last-vacuum
Kim <[EMAIL PROTECTED]> writes:
> We were running on 8.1.1 previous to upgrading to 8.2, and yes, we
> definitely have a heafty pg_class. The inheritance model is heavily used
> in our schema (the results of the group by you wanted to see are down
> below). However, no significant problems were
Hey Tom,
We were running on 8.1.1 previous to upgrading to 8.2, and yes, we
definitely have a heafty pg_class. The inheritance model is heavily used
in our schema (the results of the group by you wanted to see are down
below). However, no significant problems were seen with vacs while we
were
Kim <[EMAIL PROTECTED]> writes:
> size of pg_class: 535,226
> number of relations: 108,694
Oh, I shoulda read all the way to the bottom of your email :-(. What
version of PG were you running before? I would think that pretty much
any version of pgstat_vacuum_tabstats would have had a performance
Kim <[EMAIL PROTECTED]> writes:
> Running a vac on an 8.2 client connecting to an 8.2 database (following
> example was for a 14 row static table) - vacuums will sit (for lack of a
> better word) for anywhere from ten to twenty minutes before taking a
> lock out on the table and doing work there
Kim wrote:
OS: Solaris 10
write transactions/hr: 1.5 million
size of pg_class: 535,226
number of relations: 108,694
That is a huge pg_class. I remember some discussion recently about
problems with 8.2 and the way it scans pg_class. I also believe it's
fixed in 8.2.1. Are you running that.
Hello all!
Running a vac on an 8.2 client connecting to an 8.2 database (following
example was for a 14 row static table) - vacuums will sit (for lack of a
better word) for anywhere from ten to twenty minutes before taking a
lock out on the table and doing work there. Once the vacuum does
comp
14 matches
Mail list logo
