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: 1A5F6A38A6E4435EA09F8C27A0777616@tridecap.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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
use VACUUM ANALSE.

Dave

In response to

Browse pgsql-performance by date

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