Tom Lane escribió:
> Crash safety. The basic process in vacuum full is:
>
> * detect that there is room in a lower-numbered page to move the
> physically last tuple to.
>
> * put a copy of the last tuple there. Mark the last tuple itself
> as deleted by the VACUUM.
Hmm, I've seen people doing
Kevin Hunter <[EMAIL PROTECTED]> writes:
> Hmm. I get the reorganization bit, but so what? Since VACUUM FULL
> already has an exclusive lock, what prevents it from updating the
> indexes in-place to point to the new physical disk location? Why does
> it need to create extra bloat?
Crash safety.
Tino Wildenhain escribió:
> Which makes me think if the solution would be to just run CLUSTER under
> the hood when VACUUM FULL is requested. Would that introduce any
> other problems?
The difference is that CLUSTER requires double the disk space in table +
indexes. VACUUM FULL has no such requi
Martijn van Oosterhout wrote:
...
AIUI, people know VACUUM FULL sucks and that in the cases where it
really helps CLUSTER is faster anyway and doesn't have the index
problems. The TODO list reference several discussions on the topic.
Or, failing that, what's the reason to not issue a REINDEX CO
At 2:44p -0400 on Wed, 13 Aug 2008, Martijn van Oosterhout wrote:
> Or how about not doing VACUUM FULL at all. It's not a command that
> should be run regularly in most situations.
Heh, fair enough. My questions were rather academic anyway. :-)
I appreciate it, Martijn!
Kevin
--
Sent via pgs
On Wed, Aug 13, 2008 at 01:16:03PM -0400, Kevin Hunter wrote:
> Hmm. I get the reorganization bit, but so what? Since VACUUM FULL
> already has an exclusive lock, what prevents it from updating the
> indexes in-place to point to the new physical disk location? Why does
> it need to create extra
At 12:53p -0400 on Wed, 13 Aug 2008, Martijn van Oosterhout wrote:
> On Wed, Aug 13, 2008 at 12:41:41PM -0400, Kevin Hunter wrote:
>> Roughly, VACUUM simply reclaims/frees disk space, while VACUUM FULL
>> additionally reorganizes disk usage. I'm still don't know *why* this
>> leads to index bloat,
> Because VACUUM FULL needs to move stuff around in the table which means it
> need to mess around with the indexes (adding new entries). Ordinary
> VACUUM only needs to delete stuff so doesn't cause anywhere near as
> many problems.
so in the event that I really end up running VACUUM FULL o
On Wed, Aug 13, 2008 at 12:41:41PM -0400, Kevin Hunter wrote:
> Roughly, VACUUM simply reclaims/frees disk space, while VACUUM FULL
> additionally reorganizes disk usage. I'm still don't know *why* this
> leads to index bloat, however, just that it does. I must defer that
> explication to a Postg
At 12:04p -0400 on Tue, 12 Aug 2008, Joao Ferreira wrote:
> I'm a bit lost here. I'm currently executing VACUUM FULL _and_ REINDEX
> (tbls & idxs) every week.
>
> Should I keep the REINDEX and drop VACUUM FULL ?
>
> How do I iterate to a better approach ?
It might behoove you to read the Notes
On Tue, 2008-08-12 at 08:38 -0700, Lennin Caro wrote:
> you can use a cron job
>
I have my cron setup to do database wide vacuums each night and it
usually takes ~between 4-6 hours on ~200G DB size.
On days where there is huge activity, it can drag on for like 15+ hours.
I've recently dropped
In response to Joao Ferreira gmail <[EMAIL PROTECTED]>:
>
> On Tue, 2008-08-12 at 11:53 -0400, Tom Lane wrote:
> > TW, "more aggressive routine vacuuming" does NOT mean "use vacuum
> > full".
> > Vacuum full tends to make index bloat worse, not better.
> >
> > regards, to
On Tue, Aug 12, 2008 at 10:09 AM, William Garrison
<[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>>
>> Joao Ferreira gmail <[EMAIL PROTECTED]> writes:
>>
>>>
>>> I executed REINDEX by hand and the disk ocupation imediatelly dropped 6
>>> Giga...!!!
>>>
>>
>>
>>>
>>> is there a way to configure postg
Tom Lane wrote:
Joao Ferreira gmail <[EMAIL PROTECTED]> writes:
I executed REINDEX by hand and the disk ocupation imediatelly dropped 6
Giga...!!!
is there a way to configure postgres to automatically execute the needed
REINDEXING (on indexes and tables) for a given database
On Tue, Aug 12, 2008 at 10:04 AM, Joao Ferreira gmail
<[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-08-12 at 11:53 -0400, Tom Lane wrote:
>> TW, "more aggressive routine vacuuming" does NOT mean "use vacuum
>> full".
>> Vacuum full tends to make index bloat worse, not better.
>>
>>
On Tue, 2008-08-12 at 11:53 -0400, Tom Lane wrote:
> TW, "more aggressive routine vacuuming" does NOT mean "use vacuum
> full".
> Vacuum full tends to make index bloat worse, not better.
>
> regards, tom lane
>
Ok. so what does it mean ?
I'm a bit lost here. I'm curre
Joao Ferreira gmail <[EMAIL PROTECTED]> writes:
> I executed REINDEX by hand and the disk ocupation imediatelly dropped 6
> Giga...!!!
> is there a way to configure postgres to automatically execute the needed
> REINDEXING (on indexes and tables) for a given database
Generally speaking, there
you can use a cron job
--- On Tue, 8/12/08, Joao Ferreira gmail <[EMAIL PROTECTED]> wrote:
> From: Joao Ferreira gmail <[EMAIL PROTECTED]>
> Subject: [GENERAL] automatic REINDEX-ing
> To: "pgsql-general"
> Date: Tuesday, August 12, 2008, 3:13 PM
> Hello a
Hello all
[[[ while dealing with a disk size problem I realised my REINDEX cron
script was not really being called every week :( so... ]]]
I executed REINDEX by hand and the disk ocupation imediatelly dropped 6
Giga...!!!
is there a way to configure postgres to automatically execute the needed
19 matches
Mail list logo
