Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

2007-05-16 Thread Guillaume Cottenceau
Michael Stone mstone+postgres 'at' mathom.us writes: On Tue, May 15, 2007 at 06:43:50PM +0200, Guillaume Cottenceau wrote: patch - basically, I think the documentation under estimates (or sometimes misses) the benefit of VACUUM FULL for scans, and the needs of VACUUM FULL if the routine

Re: [PERFORM] Disk Fills Up and fsck Compresses it

2007-05-16 Thread Y Sidhu
What do you mean by softupdates? Is that a parameter in what I am guessing is the conf file? Yudhvir On 5/15/07, Jim C. Nasby [EMAIL PROTECTED] wrote: I'm guessing you're seeing the affect of softupdates. With those enabled it can take some time before the space freed by a delete will

Re: [PERFORM] New performance documentation released

2007-05-16 Thread Luke Lonergan
Cool! Now we can point people to your faq instead of repeating the dd test instructions. Thanks for normalizing this out of the list :-) - Luke On 5/15/07 8:55 PM, Greg Smith [EMAIL PROTECTED] wrote: I've been taking notes on what people ask about on this list, mixed that up with work I've

Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

2007-05-16 Thread Jim C. Nasby
On Wed, May 16, 2007 at 09:41:46AM +0200, Guillaume Cottenceau wrote: Michael Stone mstone+postgres 'at' mathom.us writes: On Tue, May 15, 2007 at 06:43:50PM +0200, Guillaume Cottenceau wrote: patch - basically, I think the documentation under estimates (or sometimes misses) the benefit

Re: [PERFORM] Disk Fills Up and fsck Compresses it

2007-05-16 Thread Jim C. Nasby
No, it's part of FreeBSD's UFS. google FreeBSD softupdates and you should get plenty of info. As I said, it's probably not worth worrying about. On Wed, May 16, 2007 at 08:21:23AM -0700, Y Sidhu wrote: What do you mean by softupdates? Is that a parameter in what I am guessing is the conf file?

Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

2007-05-16 Thread Guillaume Cottenceau
Jim C. Nasby decibel 'at' decibel.org writes: On Wed, May 16, 2007 at 09:41:46AM +0200, Guillaume Cottenceau wrote: [...] Come on, I don't suggest to remove several bold warnings about it, the best one being Therefore, frequently using VACUUM FULL can have an extremely negative effect on

Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

2007-05-16 Thread Alvaro Herrera
Guillaume Cottenceau wrote: Jim C. Nasby decibel 'at' decibel.org writes: On Wed, May 16, 2007 at 09:41:46AM +0200, Guillaume Cottenceau wrote: [...] Come on, I don't suggest to remove several bold warnings about it, the best one being Therefore, frequently using VACUUM FULL can

Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

2007-05-16 Thread Jim C. Nasby
On Wed, May 16, 2007 at 12:09:26PM -0400, Alvaro Herrera wrote: Guillaume Cottenceau wrote: Jim C. Nasby decibel 'at' decibel.org writes: On Wed, May 16, 2007 at 09:41:46AM +0200, Guillaume Cottenceau wrote: [...] Come on, I don't suggest to remove several bold warnings about

Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

2007-05-16 Thread Michael Stone
On Wed, May 16, 2007 at 12:09:26PM -0400, Alvaro Herrera wrote: Maybe, but we should also mention that CLUSTER is a likely faster workaround. Unless, of course, you don't particularly care about the order of the items in your table; you might end up wasting vastly more time rewriting tables

Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

2007-05-16 Thread Chris Browne
[EMAIL PROTECTED] (Michael Stone) writes: On Wed, May 16, 2007 at 12:09:26PM -0400, Alvaro Herrera wrote: Maybe, but we should also mention that CLUSTER is a likely faster workaround. Unless, of course, you don't particularly care about the order of the items in your table; you might end up

Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

2007-05-16 Thread Michael Stone
On Wed, May 16, 2007 at 03:34:42PM -0400, Chris Browne wrote: [EMAIL PROTECTED] (Michael Stone) writes: Unless, of course, you don't particularly care about the order of the items in your table; you might end up wasting vastly more time rewriting tables due to unnecessary clustering than for

Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

2007-05-16 Thread Alvaro Herrera
Michael Stone wrote: On Wed, May 16, 2007 at 03:34:42PM -0400, Chris Browne wrote: [EMAIL PROTECTED] (Michael Stone) writes: Unless, of course, you don't particularly care about the order of the items in your table; you might end up wasting vastly more time rewriting tables due to unnecessary

Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

2007-05-16 Thread Tom Lane
Michael Stone [EMAIL PROTECTED] writes: On Wed, May 16, 2007 at 03:34:42PM -0400, Chris Browne wrote: If CLUSTER is faster than VACUUM FULL (and if it isn't, in all cases, it *frequently* is, and probably will be, nearly always, soon), then it's a faster workaround. Cluster reorders the

Re: [PERFORM] Disk Fills Up and fsck Compresses it

2007-05-16 Thread Mark Kirkwood
Jim C. Nasby wrote: No, it's part of FreeBSD's UFS. google FreeBSD softupdates and you should get plenty of info. As I said, it's probably not worth worrying about. On Wed, May 16, 2007 at 08:21:23AM -0700, Y Sidhu wrote: What do you mean by softupdates? Is that a parameter in what I am