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
autovacuum
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 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 we have a mode where
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 at the
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
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. Now
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 autoanalyze took a
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
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).
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 size
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 tweak
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?
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
13 matches
Mail list logo
