Re: Autovacuum and Autoanalyze

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "David Fetter" <david(at)fetter(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Autovacuum and Autoanalyze
Date: 2008-09-17 20:21:49
Message-ID: 603c8f070809171321u1beaa6afo91695ec939bd73e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I tend to agree with Alvaro that there's not very much of a use case for
> an analyze-only autovacuum mode. Assuming that we get to the point of
> having a parallelizing pg_restore, it would be interesting to give it an
> option to include ANALYZE for each table it's loaded among the tasks
> that it schedules. (I'm visualizing these commands as being made up by
> pg_restore itself, *not* added to the pg_dump output.) Then you could
> have a reasonably optimal total workflow, whereas allowing autovacuum
> to try to schedule the ANALYZEs can't be.

In Simon's original email, he suggested forcing an automatic ANALYZE
on the server side after CREATE TABLE AS. I objected on the grounds
that this won't fix anything for people who are doing bulk data loads
using any other mechanism. Here, you're proposing the exact same
thing, except instead of restricting it to people who use CREATE TABLE
AS, you're restricting it to people who use a hypothetical
parallelized implementation of pg_restore.

While either of these is better than doing nothing, ISTM it would be
far better to give the database some smarts about what constitutes a
bulk data load (a whole bunch of insert operations on a newly created
table) and what to do about it (synchronous analyze just before the
first operation on the table that isn't an insert - and perhaps not
before).

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2008-09-17 20:24:09 proposal - function's default parametes
Previous Message Ron Mayer 2008-09-17 19:03:13 Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle