Search Postgresql Archives

Re: Vacuum as "easily obtained" locks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/3/2011 4:47 AM, Michael Graham wrote:
Hi all,

I have an application that is reading from a queue table, as part of my
testing I stressed the table to check performance, but after the test
was completed I have the a very large empty table:

SELECT relname, pg_size_pretty(pg_relation_size(oid)) AS size,
reltuples::bigint FROM pg_class;

           relname           |   size   | reltuples
----------------------------+----------+-----------
  logdata5queue              | 142 GB   |         0

 From reading the documentation I see that postgres would return this
space to that system after a normal vacuum if "one or more pages at the
end of a table become entirely free and an exclusive table lock can be
easily obtained".

What does "easily obtained" mean in this context?  Would my applications
constant polling of the queue mean that the lock could not be easily
obtained?

Cheers,

I'm not sure what "easily obtained" means, sorry. But here is what I can offer.

Depending on how long you ran your test, and the conf settings, and the size of your database, autovacuum may never have even tried.

If you have lots and lots of tables, autovacuum only checks one at a time, then wait's a bit. Did you run your test for several days?

You can take a look on pg_stat_all_tables, under the *vacuum columns, to see if it ever even ran. (a date in last_autovacuum would indicate a successful run, it wont show failures). It should, however, write something to the system log. I recall something like "autovacuum canceled because...something or other" type a message.

While you are running a test, you could keep an eye on the log to see if you get any of those messages. I think that would indicate autovacuum could not get a lock. You can also watch pg_stat_activity during the test, current_query will show you what table is being vacuumed.

At worst case, if your usage does prevent autovacuum from running, you can still run it yourself. Either at a scheduled downtime, or as part of your regular client sql.

-Andy

--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux