Re: ANALYZE after restore

From: Jan Wieck <janwieck(at)yahoo(dot)com>
To: Justin Clift <justin(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ANALYZE after restore
Date: 2002-04-03 16:41:19
Message-ID: 200204031641.g33GfJr32202@saturn.janwieck.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Justin Clift wrote:
> Tom Lane wrote:
> >
> > Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> > > On Wed, 3 Apr 2002, Christopher Kings-Lynne wrote:
> > >> Would it be an idea to have pg_dump append an ANALYZE; command to the end of
> > >> its dumps to assist newbies / inexperienced admins?
> >
> > > I do not think this is desired behaviour.
> >
> > I agree with Gavin here ... a forced VACUUM or ANALYZE after a restore
> > will just get in the way of people who know what they're doing, and it's
> > not at all clear that it will help people who do not.
>
> Sorry Tom and Gavin, but I feel it really comes down to our idea of what
> we're
> trying to do here :
>
> a) A database which is very self-maintaining, so people DON'T HAVE to
> learn it's intricacies in order to be getting decent performance.
> (They'll have to learn the intricacies if they want *better*
> performance)

The defaults after a restore should result in index scans
most of the time, resulting in some medium decent
performance. And PostgreSQL needs some frequent VACUUM
anyway, so after a while this problem solves itself for the
average user.

A database wide forced VACUUM on the other hand can make
things worse. I have seen scenarios, where you have to
explicitly leave out ANALYZE for specific tables in order to
keep them index-scanned. So what you're proposing is to force
professional PostgreSQL users to wait after restore for a
useless ANALYZE to complete, before they can reset things
with a normal VACUUM to get their required performance back?
And all that just to make dummies happier?

Jan

> b) A database which works. But if you want decent performance, you'd
> better
> take the time and effort to learn it.
> (This is the approach the commercial vendors take)
>
> I feel we should always target a) where it's possible to without it
> seriously
> getting in the way of people who've take the time to learn the skills.
>
> The far majority of people who use PostgreSQL are in the category which
> will
> benefit from a) so they can put their time to other uses instead of
> having to
> learn and keep-up-to-date-with PostgreSQL. This will *always* be the
> case.
>
> Having decent performance by default should definitely be an important
> objective, so having an ANALYZE command run at the end of a restore - by
> default only - is a good idea.
>
> Regards and best wishes,
>
> Justin Clift
>
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
> --
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
> - Indira Gandhi
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2002-04-03 16:45:03 Re: Suggestions please: names for function cachability
Previous Message Tom Lane 2002-04-03 16:35:30 Re: [HACKERS] Re : Solaris Performance - Profiling (Solved)