"Gnanakumar" writes:
> Does autovacuum daemon work on tables created with TEMPORARY syntax?
No. It can't, because it's unsafe for any session except the creating
session to touch a temporary table. The performance optimizations used
for temp tables have that unfortunate side-effect.
Hi,
Does autovacuum daemon work on tables created with TEMPORARY syntax?
CREATE [ { TEMPORARY | TEMP } ] TABLE table_name ...
Regards,
Gnanam
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Thanks for the update.
> The main difference is that 8.2 has only one process working at a time,
> whereas in 8.3 and later there can be several. When there's only one
> process, the only way for it to process several databases is
> sequentially; the naptime is how long to sleep between each item
Excerpts from Gnanakumar's message of jue ago 12 00:56:34 -0400 2010:
> > in 8.2 "naptime" means "time to sleep after we finish a job". So even
> > if the previous task takes an hour, it will still sleep a minute before
> > doing another round. (Note that this setting has a different meaning in
>
> in 8.2 "naptime" means "time to sleep after we finish a job". So even
> if the previous task takes an hour, it will still sleep a minute before
> doing another round. (Note that this setting has a different meaning in
> later releases).
I couldn’t understand the difference in meaning of "autov
"Gnanakumar" wrote:
> Our production server is running PostgreSQL v8.2.3
There are a lot of bug fixes and security fixes you're missing by
not using a recent minor release:
http://www.postgresql.org/support/versioning
http://www.postgresql.org/docs/8.2/static/release.html
-Kevin
--
Sen
Excerpts from Gnanakumar's message of mié ago 11 01:07:08 -0400 2010:
Hi,
> 1. Does autovacuum daemon works with one table at a time or does it work
> with multiple tables at the same time?
Only one.
> Reason to ask this question is, let's say I've "autovacuum_naptime" set to 1
> minute, and t
Hi,
Our production server is running PostgreSQL v8.2.3 on Red Hat Enterprise
Linux Server release 5 (Tikanga).
I need a clarification on how autovacuum daemon internally works/handles in
the following specific use case/situation:
1. Does autovacuum daemon works with one table at a time or does i
Gnanakumar wrote:
> >There are two separate counters for live and dead tuples, IIRC (though
> >they may not be exposed in the pg_stat views)
>
> I've a stop/start of PostgreSQL service on a daily basis. Since these 2
> counters are not stored/saved in tables and not available in pg_stat views
>
>> 1. Why need to have 2 parameters (base threshold and scale factor) to
define
>> the threshold value, when either one of the parameter is more than enough
to
>> define the threshold value. Can you explain the significance of having
both
>> parameters. What is the real-time advantage of this?
>
Gnanakumar wrote:
> 1. Why need to have 2 parameters (base threshold and scale factor) to define
> the threshold value, when either one of the parameter is more than enough to
> define the threshold value. Can you explain the significance of having both
> parameters. What is the real-time advant
Hi,
I'm using PostgreSQL 8.2.
I want to configure autovacuum daemon process in our production server in an
efficient way and take advantage of this daemon to perform vacuum and
analyze more aggressively.
I also read about autovacuum daemon at
http://www.postgresql.org/docs/8.2/interactive/routi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alvaro Herrera schrieb:
> Abdul Rahman wrote:
>> Deal All,
>>
>> I have set postgresql.conf for autovacuum and need to know weather the
>> process is running/working or not.
>
> Run this query:
> SHOW autovacuum;
way easiere than my approach ;-)
Tha
Abdul Rahman wrote:
> Deal All,
>
> I have set postgresql.conf for autovacuum and need to know weather the
> process is running/working or not.
Run this query:
SHOW autovacuum;
If it says "on", then it is working.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
T
Deal All,
I have set postgresql.conf for autovacuum and need to know weather the process
is running/working or not.
Regards,
Avdul Rehman.
Added to TODO for autovacuum:
o Consider logging activity either to the logs or a system view
---
Jeff Bohmer wrote:
>
> >>Unless I misunderstand, if stats_reset_on_server_start=off, these
> >>(currently nonexist
Unless I misunderstand, if stats_reset_on_server_start=off, these
(currently nonexistent autovacuum) stats would only be relevant for
autovacuum's VACUUM activity and not it's ANALYZE activity. In
which case, it seems ideal to keep autovacuum VACUUM stats
regardless of the GUC setting, while
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 restart
AFAIK, a restart does not affect the VACUUMed-ness of anything.
Keeping these (currently nonexistent autovacuum) stats across
restarts would be helpful if stats_reset_on_server_start=on.
Sorry, got the meaning backwards. The above should be
stats_reset_on_server_start=OFF. And the below s
This sounds more and more like a good idea. I don't think there's any
need to maintain across dump/reload and / or database restart either.
The DBA can elect to keep or discard stats data across DB restart,
in fact I think the default value for this GUC var was set to true
for the 8.1 releas
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/relo
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/reloads, ri
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 a
On Thu, 2005-11-10 at 02:04, Jeff Bohmer wrote:
> >Another thought: How about adding something to the stats system
> >that an admin can turn on / off. Maybe anew relation called
> >pg_stat_autovacuum_activity this would detail the last vacuum, last
> >analyze, number of vacuums / analyzes in t
Another thought: How about adding something to the stats system
that an admin can turn on / off. Maybe anew relation called
pg_stat_autovacuum_activity this would detail the last vacuum, last
analyze, number of vacuums / analyzes in the last 24 hours, last
month etc... I dunno, whatever pe
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 pract
I like the idea of having a autovacuum_log_min_messages. From my
previous experience the pg_autovacuum.log files have been useful in
diagnosing problems in the field.
- Joe
On 11/9/05, Tom Lane <[EMAIL PROTECTED]> wrote:
Joe Maldonado <[EMAIL PROTECTED]> writes:> I agree...for now while I'm devel
Joe Maldonado <[EMAIL PROTECTED]> writes:
> I agree...for now while I'm developing and debugging my application I can
> have the logging be that verbose...I agree that these should be handled as
> info messages, since they are invaluable in investigating problems.
This would be a pretty bad idea I
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
I agree...for now while I'm developing and debugging my application I
can have the logging be that verbose...I agree that these should be
handled as info messages, since they are invaluable in investigating
problems.
- JoeOn 11/9/05, Matthew T. O'Connor <[EMAIL PROTECTED]> wrote:
Joe Maldonado
Hello,
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?-- Joe Maldonado
31 matches
Mail list logo
