Re: Memory usage during vacuum - Mailing list pgsql-general

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 25 March 2004 09:12 am, Shelby Cain wrote:
> I agree in principle that the solution is to run on a
> server with more memory instead of my local
> development box.  However, I'm not going to be able to
> simply request that additional memory be installed as
> these are "standard" boxes that IT distributes to
> employees.

Too bad that.

>
> Regardless, I'm more curious about whether I was
> overlookign a setting that could reduce the memory
> footprint during a vacuum analyze cycle than about
> getting it reduced.  If it becomes a major pain I'll
> simply run the thing on off hours while I'm not at
> work.  :)

That's what I would do. Depending on how many transactions (inserts/deletes)
you do a day, it might be perfectly fine to just run a vacuum full analyze
every night via cron. You can reduce the per connection settings (max
connections allowed as well as shared buffers), but that may have a rather
significant impact on performance. So it's probably best to leave those
settings alone (when developing you don't want to wait a minute per query)
and rather do the cleanup at night, or maybe an additional one during lunch
(if needed).

>
> Regards,
>
> Shelby Cain
>
> --- "Uwe C. Schroeder" <uwe@oss4u.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > How about plugging in more memory ?
> > 40MB seems a bit low for a database server footprint
> > - well, certainly depends
> > on what you do.
> > But if your machine starts swapping with an extra 40
> > MB of memory consumption
> > I'd say the machine is undersized for the
> > application. I usually have around
> > 500 MB free memory with everything running. Memory
> > is cheap nowadays...
> >
> > On Thursday 25 March 2004 08:15 am, Tom Lane wrote:
> > > Shelby Cain <alyandon@yahoo.com> writes:
> > > > I'm trying to keep postgresql's memory usage
> > > > under 40 megs under all conditions so that other
> > > > services/applications don't grind to a halt due
> >
> > to
> >
> > > > swapping.  Is there any way to achieve my goal?
> > >
> > > Don't use VACUUM FULL.  The vacuum_mem setting
> >
> > only limits the space
> >
> > > consumed by plain VACUUM --- VACUUM FULL needs to
> >
> > keep track of all the
> >
> > > free space in the table, and will eat as much
> >
> > memory as it has to to do
> >
> > > that.
> > >
> > >             regards, tom lane
> > >
> > > ---------------------------(end of
> >
> > broadcast)---------------------------
> >
> > > TIP 9: the planner will ignore your desire to
> >
> > choose an index scan if your
> >
> > >       joining column's datatypes do not match
> >
> > - --
> >     UC
> >
> > - --
> > Open Source Solutions 4U, LLC    2570 Fleetwood Drive
> > Phone:  +1 650 872 2425        San Bruno, CA 94066
> > Cell:   +1 650 302 2405        United States
> > Fax:    +1 650 872 2417
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.3 (GNU/Linux)
>
> iD8DBQFAYw22jqGXBvRToM4RAghbAKCbXZ9avDIMwpxOyo3g+iyoTmJNSQCgkk3n
>
> > 2a8HrY9gxBNMk/2iwLrnHEA=
> > =TZob
> > -----END PGP SIGNATURE-----
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Finance Tax Center - File online. File on time.
> http://taxes.yahoo.com/filing.html

- --
    UC

- --
Open Source Solutions 4U, LLC    2570 Fleetwood Drive
Phone:  +1 650 872 2425        San Bruno, CA 94066
Cell:   +1 650 302 2405        United States
Fax:    +1 650 872 2417
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAYxazjqGXBvRToM4RAh1RAKCV9ozDim5gBWYdX+VBdyiT8Ych1QCgyqZb
Eo6UT9r2K2z6TE1jQpg/PEU=
=4ogO
-----END PGP SIGNATURE-----