uninformed in that we have not put the OO/OR features to the side, and, in
fact, have developers actively working on it ...
On Thu, 13 Apr 2000 [EMAIL PROTECTED] wrote:
>
>
> On Thu, 13 Apr 2000, The Hermit Hacker wrote:
>
> > On Wed, 12 Apr 2000 [EMAIL PROTECTED] wrote:
> >
> > >
> > > pe
Matthew Arnison wrote:
>
> three times now this week (on two different servers) the raw database on
> disk has ballooned in size, from about 10 megs to 50 megs in two cases,
> and from about 10 megs to 250 megs in another case.
>
> a VACUUM VERBOSE ANALYZE; cleans it back down to the proper size
> > this is a totally uninformed and inaccurate assessment ... the current
> > state of OO/OR features in PgSQL has been sitting pretty much on one
> > persons shoulders ... v7.0 has some extensions/fixes added in this arena,
> > and we would very much welcome anyone that wishes to work with us to
[EMAIL PROTECTED] wrote:
>
> On Thu, 13 Apr 2000, The Hermit Hacker wrote:
>
> > On Wed, 12 Apr 2000 [EMAIL PROTECTED] wrote:
> >
> > > perhaps you'd better first find an evaluation copy of informix, seems that
> > > they have more systematic and well-thought feature set.
> > >
> > > there are s
On Thu, 13 Apr 2000, Ed Loehr wrote:
> Kaiq may be wrong, possibly not knowing of more informative conversations
> going on in the private pgsql mailing lists (pg-core, etc.), but he is not
> coming from left field.
wow, there is a pg-core, can I get in? -- ok, maybe later, after I prove
myself
I think I found it myself under FAQ 4.5, - Thanks and sorry for posting
this.
I think I found it myself under FAQ 4.5, - Thanks and sorry for posting
this.
"Aage J. Skjolingstad" wrote:
>
> Have tried searching for this but it does not return any results today;
> - only me having this problem ?
Ed Loehr wrote:
> ... it is a well-known "postgresqlism"
> that you should consider running vacuum analyze at least nightly, possibly
> more frequently. [I run it hourly.]
I think there must be something wrong with the optimiser that it's
"postgresqlism" that you must vacuum analyze frequently.
On Fri, 14 Apr 2000, Thomas wrote:
> For large 24x7 installations, it's impossible to vacuum nightly because when
> postgresql is vacuuming the table is locked up, to the end-user the database
> has already hung.
That's right. I complained about this in a discussion with a Postgresql
developer,
On Fri, 14 Apr 2000, Thomas wrote:
> For large 24x7 installations, it's impossible to vacuum nightly because when
> postgresql is vacuuming the table is locked up, to the end-user the database
> has already hung.
That's right. I complained about this in a discussion with a Postgresql
developer
the bloat is a big problem. i just checked it again, and the db has
balloooned to 20 megs again, with i think 2650 unused pages. this is after
vacuuming it last night. i guess we need to setup the vacuum script to run
every hour. i am worried about this locking out users during the
vacuuming, alth
10 matches
Mail list logo
