> 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
> tha
On Wed, 2008-09-17 at 10:52 -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> Why doesn't this new request conflict with that one?
>
> > The problem back then was that a CREATE INDEX was waiting on the
> > autoanalyze to finish, and the autoana
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Why doesn't this new request conflict with that one?
> The problem back then was that a CREATE INDEX was waiting on the
> autoanalyze to finish, and the autoanalyze took a long time to finish
> because of vacuum_cost_delay
Alvaro Herrera wrote:
Simon Riggs wrote:
On Wed, 2008-09-17 at 10:09 +0300, Heikki Linnakangas wrote:
Isn't autoanalyze a waste of time during a bulk load? Seems better to
run ANALYZE manually at the end.
Its not a waste of time because it catches tables immediately they have
been loaded, not
Simon Riggs wrote:
>
> On Wed, 2008-09-17 at 10:09 +0300, Heikki Linnakangas wrote:
> > Isn't autoanalyze a waste of time during a bulk load? Seems better to
> > run ANALYZE manually at the end.
>
> Its not a waste of time because it catches tables immediately they have
> been loaded, not just
On Wed, 2008-09-17 at 10:09 +0300, Heikki Linnakangas wrote:
> David Fetter wrote:
> > On Tue, Sep 16, 2008 at 08:59:08PM -0400, Alvaro Herrera wrote:
> >> Simon Riggs wrote:
> >>> Disabling autovacuum can have catastrophic effects, since it disables
> >>> the ANALYZing of tables.
> >>>
> >>> Can
David Fetter wrote:
On Tue, Sep 16, 2008 at 08:59:08PM -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
Disabling autovacuum can have catastrophic effects, since it disables
the ANALYZing of tables.
Can we have a mode where we disable autoVACUUM yet enable autoANALYZE?
You mean something like
On Tue, Sep 16, 2008 at 08:59:08PM -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > Disabling autovacuum can have catastrophic effects, since it disables
> > the ANALYZing of tables.
> >
> > Can we have a mode where we disable autoVACUUM yet enable autoANALYZE?
>
> You mean something like
>
Simon Riggs wrote:
> Disabling autovacuum can have catastrophic effects, since it disables
> the ANALYZing of tables.
>
> Can we have a mode where we disable autoVACUUM yet enable autoANALYZE?
You mean something like
autovacuum = on / off / analyze ?
We can certainly do that, but is there buy-in
> Please provide some specifics. It's been a very long time since the
> planner was completely unaware of the size of such a table. Lack of
> stats is certainly a handicap, but I'm not convinced it should result
> in horrible plans. Maybe a more appropriate answer to this type of
> issue is to t
"Robert Haas" <[EMAIL PROTECTED]> writes:
> This seems like the wrong solution. There is a general problem that
> bulk data loads on an empty table tend to result in horrible query
> plans,
Please provide some specifics. It's been a very long time since the
planner was completely unaware of the
> Disabling autovacuum can have catastrophic effects, since it disables
> the ANALYZing of tables.
>
> Can we have a mode where we disable autoVACUUM yet enable autoANALYZE?
>
> ANALYZE times are fairly bounded because of the way we do sampling.
> VACUUM times are not bounded at all, and typically
Disabling autovacuum can have catastrophic effects, since it disables
the ANALYZing of tables.
Can we have a mode where we disable autoVACUUM yet enable autoANALYZE?
ANALYZE times are fairly bounded because of the way we do sampling.
VACUUM times are not bounded at all, and typically > O(n). So i
13 matches
Mail list logo
