Re: ANALYZE after restore - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: ANALYZE after restore
Date
Msg-id 200204031641.g33GfJr32202@saturn.janwieck.net
Whole thread Raw
In response to Re: ANALYZE after restore  (Justin Clift <justin@postgresql.org>)
Responses Re: ANALYZE after restore  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Justin Clift wrote:
> Tom Lane wrote:
> >
> > Gavin Sherry <swm@linuxworld.com.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
proposingis 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
makedummies 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@postgresql.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@Yahoo.com #




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Re : Solaris Performance - Profiling (Solved)
Next
From: Peter Eisentraut
Date:
Subject: Re: Suggestions please: names for function cachability