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
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 |