Skip site navigation (1) Skip section navigation (2)

Re: Postgresql optimisation

From: "Dave Dutcher" <dave(at)tridecap(dot)com>
To: "'Matthew Wakeling'" <matthew(at)flymine(dot)org>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Postgresql optimisation
Date: 2009-10-28 17:23:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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


In response to

pgsql-performance by date

Next:From: Anj AduDate: 2009-10-28 18:13:42
Subject: sub-select in IN clause results in sequential scan
Previous:From: Matthew WakelingDate: 2009-10-28 16:36:52
Subject: Re: Postgresql optimisation

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group