From: | MirrorX <mirrorx(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | vacuum internals and performance affect |
Date: | 2011-11-29 17:12:13 |
Message-ID: | 1322586733308-5033043.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | Benjamin Johnson | 2011-11-30 15:27:35 | Guidance Requested - Bulk Inserting + Queries |
Previous Message | Marcus Engene | 2011-11-29 16:58:56 | Re: WAL in RAM |