On Fri, 21 Nov 2003, Matthew T. O'Connor wrote:
> >> Do you know of an easy way to get a
> >>count of the total pages used by a whole cluster?
> >
> >Select sum(relpages) from pg_class.
You might want to exclude indexes from this calculation. Some large
read only tables might have indexes larger t
Josh Berkus <[EMAIL PROTECTED]> writes:
> BTW, do we have any provisions to avoid overlapping vacuums? That is, to
> prevent a second vacuum on a table if an earlier one is still running?
Yes, VACUUM takes a lock that prevents another VACUUM on the same table.
regards, t
Josh Berkus wrote:
Matthew,
I certainly agree that less than 10% would be excessive, I still feel
that 10% may not be high enough though. That's why I kinda liked the
sliding scale I mentioned earlier, because I agree that for very large
tables, something as low as 10% might be useful, but
Matthew,
> Basically, I don't like the idea of modifying users databases, besides,
> in the long run most of what needs to be tracked will be moved to the
> system catalogs. I kind of consider the pg_autvacuum database to
> equivalent to the changes that will need to be made to the system cata
Josh Berkus wrote:
Matthew,
I don't see how a seperate database is better than a table in the databases.,
except that it means scanning only one table and not one per database. For
one thing, making it a seperate database could make it hard to back up and
move your database+pg_avd config.
Matthew,
> Actually, this might be a necessary addition as pg_autovacuum currently
> suffers from the startup transients that the FSM used to suffer from,
> that is, it doesn't remember anything that happened the last time it
> ran. A pg_autovacuum database could also be used to store threshol
Josh Berkus wrote:
Matthew,
But we could create a config file that would store stuff in a flatfile table,
OR we could add our own "system table" that would be created when one
"initializes" pg_avd.
I don't want to add tables to existing databases, as I consider that
clutter and I never li
Matthew,
> As long as pg_autovacuum remains a contrib module, I don't think any
> changes to the system catelogs will be make. If pg_autovacuum is
> deemed ready to move out of contrib, then we can talk about the above.
But we could create a config file that would store stuff in a flatfile tabl
Shridhar Daithankar wrote:
Matthew T. O'Connor wrote:
But we track tuples because we can compare against the count given by
the stats system. I don't know of a way (other than looking at the
FSM, or contrib/pgstattuple ) to see how many dead pages exist.
I think making pg_autovacuum dependent
Matthew T. O'Connor wrote:
But we track tuples because we can compare against the count given by
the stats system. I don't know of a way (other than looking at the FSM,
or contrib/pgstattuple ) to see how many dead pages exist.
I think making pg_autovacuum dependent of pgstattuple is very good
Josh Berkus wrote:
Matthew,
True, but I think it would be one hour once, rather than 30 minutes 4
times.
Well, generally it would be about 6-8 times at 2-4 minutes each.
Are you saying that you can vacuum a 1 million row table in 2-4
minutes? While a vacuum of the same table with an a
Ryszard Lach <[EMAIL PROTECTED]> writes:
> It seems, that empty statements are generated during opening of
> connection.
Hmm. Try asking about that on the pgsql-jdbc list. I think the JDBC
driver must actually be sending empty commands.
Looking at the backend code, I realize that 7.4 will emit
On Thu, 2003-11-20 at 19:40, Matthew T. O'Connor wrote:
> I'm open to discussion on changing the defaults. Perhaps what it would
> be better to use some non-linear (perhaps logorithmic) scaling factor.
> So that you wound up with something roughly like this:
>
> #tuples activity% for vacuum
On Thu, Nov 20, 2003 at 07:17:01PM -0500, Tom Lane wrote:
>
>
> Is it possible that you're sending a lot of queries that have an initial
> newline in the text? I'd expect the first line of log output for such a
> query to look as above.
I don't think so, but it is possible, that queries have e.
14 matches
Mail list logo
