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.g.
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
1k
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
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
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
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,
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 table,
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 like
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 thresholds
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
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
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,
12 matches
Mail list logo
