Re: Postgresql optimisation

Поиск
Список
Период
Сортировка
От Dave Dutcher
Тема Re: Postgresql optimisation
Дата
Msg-id 1A5F6A38A6E4435EA09F8C27A0777616@tridecap.com
обсуждение исходный текст
Ответ на Re: Postgresql optimisation  (Matthew Wakeling <matthew@flymine.org>)
Список 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 по дате отправления:

Предыдущее
От: Matthew Wakeling
Дата:
Сообщение: Re: Postgresql optimisation
Следующее
От: Anj Adu
Дата:
Сообщение: sub-select in IN clause results in sequential scan