------=_Part_883_8705078.1209467140512
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
From most of the reply found that upgrade to higher version of postgres
may
be to 8.3.1 may be one of the solution to tackle this problem
Checked about HOT feature in 8.3.1.
Do we need to do any special config changes or any other setting for HOT
to
work??
Any special guideline to follow to make HOT working??
~ Gauri
On Tue, Apr 29, 2008 at 2:07 PM, Greg Smith <gsmith@[EMAIL PROTECTED]
> wrote:
> On Tue, 29 Apr 2008, Gauri Kanekar wrote:
>
> We do vacuum full, as vacuum verbose analyse dont regain space for us.
> >
>
> Ah, now we're getting to the root of your problem here. You expect that
> VACUUM should reclaim space.
>
> Whenever you UPDATE a row, it writes a new one out, then switches to use
> that version. This leaves behind the original. Those now unused rows
are
> what VACUUM gathers, but it doesn't give that space back to the
operating
> system.
>
> The model here assumes that you'll need that space again for the next
time
> you UPDATE or INSERT a row. So instead VACUUM just keeps those
available
> for database reuse rather than returning it to the operating system.
>
> Now, if you don't VACUUM frequently enough, this model breaks down, and
> the table can get bigger with space that may never get reused. The idea
is
> that you should be VACUUMing up now unneeded rows at about the same rate
> they're being re-used. When you don't keep up, the database can expand
in
> space that you don't get back again. The right answer to this problem
is
> not to use VACUUM FULL; it's to use regular VACUUM more often.
>
>
> --
> * Greg Smith gsmith@[EMAIL PROTECTED]
http://www.gregsmith.com
Baltimore, MD
>
--
Regards
Gauri
------=_Part_883_8705078.1209467140512
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
From most of the reply found that upgrade to higher version of
postgres may be to 8.3.1 may be one of the solution to tackle this
problem<br><br>Checked about HOT feature in <a
href="http://8.3.1.">8.3.1.</a><br><br>Do
we need to do any special config
changes or any other setting for HOT to work??<br>
<br>Any special guideline to follow to make HOT working??<br><br>~
Gauri<br><br><div class="gmail_quote">On Tue, Apr 29, 2008 at 2:07 PM,
Greg Smith <<a
href="mailto:gsmith@[EMAIL PROTECTED]
">gsmith@[EMAIL PROTECTED]
>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204,
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div
class="Ih2E3d">On Tue, 29 Apr 2008, Gauri Kanekar wrote:<br>
<br>
</div><div class="Ih2E3d"><blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
We do vacuum full, as vacuum verbose analyse dont regain space for us.<br>
</blockquote>
<br></div>
Ah, now we're getting to the root of your problem here. You
expect that VACUUM should reclaim space.<br>
<br>
Whenever you UPDATE a row, it writes a new one out, then switches to use
that version. This leaves behind the original. Those now
unused rows are what VACUUM gathers, but it doesn't give that space
back to the operating system.<br>
<br>
The model here assumes that you'll need that space again for the next
time you UPDATE or INSERT a row. So instead VACUUM just keeps those
available for database reuse rather than returning it to the operating
system.<br>
<br>
Now, if you don't VACUUM frequently enough, this model breaks down,
and the table can get bigger with space that may never get reused.
The idea is that you should be VACUUMing up now unneeded rows at
about the same rate they're being re-used. When you don't
keep up, the database can expand in space that you don't get back
again. The right answer to this problem is not to use VACUUM FULL;
it's to use regular VACUUM more often.<div>
<div></div><div class="Wj3C7c"><br>
<br>
--<br>
* Greg Smith <a href="mailto:gsmith@[EMAIL PROTECTED]
"
target="_blank">gsmith@[EMAIL PROTECTED]
> <a
href="http://www.gregsmith.com"
target="_blank">http://www.gregsmith.com</a>
Baltimore, MD<br>
</div></div></blockquote></div><br><br clear="all"><br>--
<br>Regards<br>Gauri
------=_Part_883_8705078.1209467140512--
|
