Re: Is the database being VACUUMed? - Mailing list pgsql-admin

From Chris Browne
Subject Re: Is the database being VACUUMed?
Date
Msg-id 6064nneznu.fsf@dba2.int.libertyrms.com
Whole thread Raw
In response to Is the database being VACUUMed?  ("C. Bensend" <benny@bennyvision.com>)
Responses Re: Is the database being VACUUMed?  ("C. Bensend" <benny@bennyvision.com>)
List pgsql-admin
benny@bennyvision.com ("C. Bensend") writes:
> Hey folks,
>
>    I'm running 8.0.4 on OpenBSD, and I'm running into issues where
> a large batch job will fire up and occasionally coincide with a
> VACUUM.  Which then makes this batch take an hour and a half,
> rather than the 30 minutes it usually takes.  :(
>
>    I am going to upgrade to 8.1.2 this weekend, before you ask.  :)
>
>    Here's the question - is there a query I can make in my scripts
> (using perl/DBD::Pg) to see if the database is being VACUUMed at
> the current time?  I could add a sleep, so the script would
> patiently wait for the VACUUM to finish before kicking off several
> intense queries.
>
>    Thanks much!

If you have command string monitoring turned on, via
stats_command_string in the postgresql.conf file, then you could get
this information from the system view pg_stat_activity.

Generally, you could look to see if a current_query is a vacuum, perhaps via...

select * from pg_stat_activity where lower(current_query) like 'vacuum%' ;

If that parameter is not turned on, then ps auxww | egrep [something
finding your PG processes] | grep VACUUM could perhaps do the trick,
albeit not from a straightforward database query...
--
output = ("cbbrowne" "@" "acm.org")
http://www.ntlug.org/~cbbrowne/advocacy.html
"Is your pencil Y2K certified?  Do you know the possible effects if it
isn't?"

pgsql-admin by date:

Previous
From: Stephen Frost
Date:
Subject: Re: performance question related to pgsql
Next
From: "C. Bensend"
Date:
Subject: Re: Is the database being VACUUMed?