Michael Monnerie wrote:
Dear list, this is postgres 8.1, and I run a dbmail mailserver where we deleted
most e-mails.
I then did a VACUUM (see below), and just before the dbmail_messages
truncated rows
there was a very long time where obviously nothing happened. No CPU usage (8%)
and
no disk
Rafael Domiciano wrote:
I'm not using autovacuum. Regular vacuum goes ok.
To see the last 10 lines of verbose i will need to run vacuum tonight
If a run a reindex before the vacuum full, increase the speed of
doing vacuum? I found something about it googling.
It might help a bit, but by the
Alvaro Herrera wrote:
Matthew T. O'Connor escribió:
As Alvaro already said this is a case where autovacuum still isn't
great.
While I have your attention ;-) do you have any ideas on how to improve
this? I don't see anything that looks like a solution for this case.
No good ideas
Chris Hoover wrote:
Another question.
When autovacuum sleeps, does it release the lock it has on the table?
What we would like to have happen is for vacuum to work for a while,
sleep, and while it is sleeping run an analyze on the table. We need
this due to how quickly our data is
Hello, I've been looking into having apache log to postgresql, and it
isn't clear to me what the best way to set this up is. The options
that I see so far are:
1) Apache Pipe Logging: This seems simple enough, but I'm not sure
what tool I would as the logging process?
2) pgLOGd: This
Hello, I've been looking into having apache log to postgresql, and it
isn't clear to me what the best way to set this up is. The options that
I see so far are:
1) Apache Pipe Logging: This seems simple enough, but I'm not sure what
tool I would as the logging process?
2) pgLOGd: This
Kieran Cooper, Lyris UK wrote:
We're managing a database on version 8.2.3 (running Lyris ListManager
email software). I ran a 'vacuum analyze full verbose' (we haven't been
able to get autovacuum to work properly on Lyris installs so we need to
run a full vacuum every week or so, and we'd been
Yes, because all these messages really mean is that autovacuum woke up,
and looked at database xx, it may or may not have decided to do anything
(analyze or vacuum) and judging by the fact that these messages are
almost exactly 1 minute apart, I would say that autovacuum never felt
the need to
Tobias Brox wrote:
[Matthew T. O'Connor - Wed at 02:33:10PM -0400]
In addition autovacuum respects the work of manual or cron based
vacuums, so if you issue a vacuum right after a daily batch insert /
update, autovacuum won't repeat the work of that manual vacuum.
I was experimenting
Sriram Dandapani wrote:
The only issue I have with autovacuum is the fact that I have to briefly
stop/restart postgres every couple of days, which kills autovacuum and
it has no memory of previous work done. I work with several databases
with partitioned tables having high daily volume. Dropping
Sriram Dandapani wrote:
If I were to specify in the pg_autovacuum catalog that certain high
volume partitioned tables(that get dropped daily) be ignored, then
when autovacuum finishes, will it update the transaction id wraparound
counter (this way, I can get autovacuum to finish quickly )
Csaba Nagy wrote:
On Wed, 2006-09-27 at 18:08, Edoardo Ceccarelli wrote:
How can I configure the vacuum to run after the daily batch insert/update?
Check out this:
http://www.postgresql.org/docs/8.1/static/catalog-pg-autovacuum.html
By inserting the right row you can disable
Arnau wrote:
I'm migrating our DDBB from postgresql 7.4 to postgresql 8.1. In
postgreql 7.4 we don't have autovaccum running. So, every night before
doing the daily backup we do a vaccuumdb -f -z for each DB. My doubt
is, the autovaccuum with the version 8.1 is started by default and I
don't
Sriram Dandapani wrote:
Hi
Is it possible to tell autovacuum to ignore certain tables (These
tables are high traffic daily partition tables that get dropped every
other day).
I am trying to get autovacuum to complete quicker and prevent Xactn
wraparound (currently, it takes very
Eamonn Kent wrote:
I am using PostgreSQL 8.1.4 for an embedded application. For some
reason, vacuum is not able to identify rows that are candidates for
removal (i.e., mark space as available).
[snip]
If I shutdown our application and run a vacuum full, the space is
recovered and the
Alvaro Herrera wrote:
Tom Lane wrote:
Hm. I believe that autovac only does database-wide vacuums when it
thinks they're necessary to prevent transaction wraparound failures.
Which would mean that it'd let pg_clog grow to something on the order
of half a gig before any truncation would happen.
I think the closest approximation of disabling autovacuum on a per
database basis is to connect to the database in question and perform:
update pg_autovacuum set enabled = 'false';
This will prevent autovacuum from vacuuming or analyzing any of the
tables in the database, but will still
Alvaro Herrera wrote:
Chris Browne wrote:
It strikes me as a slick idea for autovacuum to take on that
behaviour. If the daily backup runs for 2h, then it is quite futile
to bother vacuuming a table multiple times during that 2h period when
none of the tuples obsoleted during the 2h period
Jim C. Nasby wrote:
Small tables are most likely to have either very few updates (ie: a
'lookup table') or very frequent updates (ie: a table implementing a
queue). In the former, even with vacuum_threshold = 0 vacuum will be a
very rare occurance. In the later case, a high threshold is likely
Legit concern. However one of the things that autovacuum is supposed to
do is not vacuum tables that don't need it. This can result in an overal
reduction in vacuum overhead. In addition, if you see that autovacuum is
firing off vacuum commands during the day and they are impacting your
As Alvaro already mentioned this is fixed in 8.1 because it was
integrated into the backend and benifits from the logging features that
backend already has developed.
As for the 7.4.x 8.0.x versions of contrib autovacuum, I don't think
there are any plans for improving it. Also, added it to
Unfortunately, you are correct, there is no way to tell
contrib/autovacuum to rotate it's logs.
Ameet Kini wrote:
Hello,
I'm using postgresql 8.0 and am using contrib/pg_autovacuum. Is there a
way to tell pg_autovacuum to rotate the log that it generates after
it reaches a particular size?
I don't have any RHES 4.0 boxen, but I do have a CentOS 4.1 box. You
can get RPMS for the new version of PostgreSQL, you will probably want
to install a compat rpm that has the libraries that the other software
on the system requires. I forget where I downloaded mine from, but
someone on one
Scott Marlowe wrote:
I would appreciate an easy way to keep tabs on autovacuum's activity.
A stat table seems like a practical way to have this info readily
available.
No need to keep values across dump/reloads, right?
This sounds more and more like a good idea. I don't think there's
Scott Marlowe wrote:
On Thu, 2005-11-10 at 09:56, Matthew T. O'Connor wrote:
Scott Marlowe wrote:
I would appreciate an easy way to keep tabs on autovacuum's activity.
A stat table seems like a practical way to have this info readily
available.
No need to keep values across dump
Jeff Bohmer wrote:
I assumed (perhaps incorrectly) that you were talking about
maintaining the data in the theoretical / not yet in existence
autovacuum stats table through database restart, the stats system
already has a GUC var that dictates whether or not it dumps it's data
upon DB
Joe Maldonado wrote:
I have not seen any information so far on this but is there a way to
get the autovacuum daemon in PostgreSQL 8.1 to log the tables which it
is perfoming vacuum or analyze operation on?
I think the autovacuum daemon does log it's activity however all it's
output is set at
Tom Lane wrote:
This would be a pretty bad idea IMHO, since it would lead to bloating
the logs with autovacuum progress messages by default --- and whatever
you may think about it, I really doubt that the average DBA will want
those messages there all the time.
I wonder whether it would be
Enzo D'addario wrote:
Hi All,
I currently have postgres 7.4.2 running on a dedicated server which has
1GB RAM, a Pentium 4 2600 Mhz processor, uses ReiserFS filesystem and is
running Debian stable.
After approximately 1 month I have to dump restore the database
because vacuum time spirals
If you could connect to the database server from the web server and get
data with PGAdmin then it doesn't' sound like a database or database
server problem. How is your web app connecting to the database? ODBC?
That might be a bit of an issue. PgAdmin doesn't use ODBC, it uses
libpq
I have a (hopefully simple) question regarding locale.
I am migrating a postgresql database from a server running FC1
PostgreSQL 7.4 to a newer machine running FC2 and PostgreSQL 8.0. I
dumped the data from the old server using pg_dumpall and restored it to
the new server with no problems,
Steve Crawford wrote:
On Monday 21 March 2005 11:40 am, Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net 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
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
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
pg_autovacuum should work against Postgresql 7.3.x. I don't know if
compiling it from source, or using a 7.4 rpm will be easier
Theo Galanakis wrote:
Hi,
We are currently running an older version of postgres on linux
redhat, the auto_vacuum is not part of the contrib package for
Sudhakar Kurumella wrote:
We have to move from Linux based PostgreSQL to Windows based
PostgreSQL. Highly appreciated for Any ideas of smooth export/import
options.
You do know that the native windows version of PostgreSQL is still only
in Beta. The cygwin port has never really been considered
36 matches
Mail list logo
