Re: Postgresql optimisation - Mailing list pgsql-performance

From Dave Dutcher
Subject Re: Postgresql optimisation
Date
Msg-id 1A5F6A38A6E4435EA09F8C27A0777616@tridecap.com
Whole thread Raw
In response to Re: Postgresql optimisation  (Matthew Wakeling <matthew@flymine.org>)
List pgsql-performance
> From: Matthew Wakeling
>
> Perhaps reading the other replies in the thread before
> replying yourself might be advisable, because this previous
> reply directly contradicts you:
>
> On Wed, 28 Oct 2009, Kevin Grittner wrote:
> > I recommend VACUUM ANALYZE of the table(s) after this step. Without
> > that, the first query to read each tuple sets its hint bits and
> > rewrites it, causing a surprising delay at unpredictable times
> > (although heavier near the start of the day).
>
> There *is* a benefit of running VACUUM ANALYSE rather than
> just ANALYSE.
>
> Matthew

I did read the other replies first, I guess I just missed Kevin Grittner's
somehow.  I noticed several people were worried the OP had problems with
bloat, which is why I suggested TRUNCATE if possible.  That was my main
point.  I guess I made the other comment because I feel beginners with
postgres quite often don't understand the difference between VACUUM and
ANALYSE, and for large tables an ANALYSE alone can take much less time.  I
didn't think about hint bits because I've never noticed a big impact from
them, but that is probably just because of my particular situation.  Now
that it has been pointed out to me I agree it is good advise for the OP to
use VACUUM ANALSE.

Dave



pgsql-performance by date:

Previous
From: Matthew Wakeling
Date:
Subject: Re: Postgresql optimisation
Next
From: Anj Adu
Date:
Subject: sub-select in IN clause results in sequential scan