From: MirrorX <mirrorx@gmail.com>
To: pgsql-performance@postgresql.org
Subject: vacuum internals and performance affect
Date: Tue, 29 Nov 2011 09:12:13 -0800 (PST)
Message-ID: <1322586733308-5033043.post@n5.nabble.com> (raw)
dear all,
i am trying to understand if i am missing something on how vacuum works. i
ve read the manual, and did some research on the web about that but i am
still not sure.
to my understanding, vacuum just marks the dead rows of a table so that from
that point on that space would be re-used for new inserts and new updates on
that specific table. however, if there is an open transaction, vacuum can
only do what is described above up to the point that the open transaction
was started. so if for example there is a query running for 1 day, no matter
how many times i will have vacuumed the table (manual or auto), the dead
rows wont be possible to be marked as re-usable space.
-is the above correct?
-is there something more about vacuum in that case i am describing? would
for example mark the rows as 'semi-dead' so that when a scan would be made
these rows wouldn't be checked and so the queries would be faster? is there
anything else for this specific case?
-would there be any effect from the vacuum on the indexes of the table?like
i said above for the table, would the entries of the index not be scanned
for a query, due to some reason?
if there is a something i could read to answer these questions plz point me
to that direction, otherwise i would really appreciate any information you
may have. thx in advance
--
View this message in context: http://postgresql.1045698.n5.nabble.com/vacuum-internals-and-performance-affect-tp5033043p5033043.ht...
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mirrorx@gmail.com
Subject: Re: vacuum internals and performance affect
In-Reply-To: <1322586733308-5033043.post@n5.nabble.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox