> > The conventional VACUUM would then be something you do as part of a DB
> > reorganization (maybe once every month or so).
>
> Yes, but in other DB's if you UPDATE all rows in the table, you don't
> double the disk space.
Sure, but what is wrong with keeping the space allocated for the next
> > > The conventional VACUUM would then be something you do as part of a DB
> > > reorganization (maybe once every month or so).
> >
> > Yes, but in other DB's if you UPDATE all rows in the table, you don't
> > double the disk space.
>
> Sure, but what is wrong with keeping the space allocated f
>
> > I also think we have to leave VACUUM alone and come up with a new name
> > for our light VACUUM. That way, people who do VACUUM at night when no
> > one is on the system can keep doing that, and just add something to run
> > light vacuum periodically during the day.
>
> If I understood wh
> I also think we have to leave VACUUM alone and come up with a new name
> for our light VACUUM. That way, people who do VACUUM at night when no
> one is on the system can keep doing that, and just add something to run
> light vacuum periodically during the day.
If I understood what VACUUM ligh
> > That might happen eventually, but I'm not all that eager to convert
> > the postmaster into a (half-baked) substitute for cron. My experience
> > as a dbadmin is that you need various sorts of routinely-run maintenance
> > tasks anyway; VACUUM is only one of them. So you're gonna need some
>
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> If it becomes non-intrusive, then why not have PostgreSQL run VACUUM
> automatically
That might happen eventually, but I'm not all that eager to convert
the postmaster into a (half-baked) substitute for cron. My experience
as a dbadmin is t
> You'll still need to VACUUM to get rid of the obsoleted versions of the
> row. The point of the planned 7.2 changes is to make VACUUM cheap and
> nonintrusive enough so that you can run it frequently on tables that are
> seeing continual updates.
If it becomes non-intrusive, then why not have
> That might happen eventually, but I'm not all that eager to convert
> the postmaster into a (half-baked) substitute for cron. My experience
> as a dbadmin is that you need various sorts of routinely-run maintenance
> tasks anyway; VACUUM is only one of them. So you're gonna need some
> cron ta
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> Would 7.2 maintain performance when updating a row repeatedly (update,
> commit)?
You'll still need to VACUUM to get rid of the obsoleted versions of the
row. The point of the planned 7.2 changes is to make VACUUM cheap and
nonintrusive enough so that y
At 05:59 PM 7/6/01 -0400, Bruce Momjian wrote:
>
>OK, I just talked to Tom on the phone and here is his idea for 7.2. He
>says he already posted this, but I missed it.
>
>His idea is that in 7.2 VACUUM will only move rows within pages. It
>will also store unused space locations into shared memor
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> In 7.2, VACUUM will not require an exclusive lock.
>
> > Care to elaborate on that? How are you going to do it?
>
> Uh, have you not been paying attention to pg-hackers for the
> last two months?
>
> I am assuming here that concurrent VACUUM wil
11 matches
Mail list logo
