There is currently a performance tip to run ANALYZE after a pg_dump
script has been restored.
ISTM that pg_dump should default to have ANALYZE statements for a table,
when both table definition and data are dumped. If only data (-a) or
only table definition (-s) is dumped the default should be to
Simon Riggs [EMAIL PROTECTED] writes:
ISTM that pg_dump should default to have ANALYZE statements for a table,
when both table definition and data are dumped. If only data (-a) or
only table definition (-s) is dumped the default should be to *not* add
an ANALYZE statement.
Having pg_dump emit
Simon Riggs wrote:
There is currently a performance tip to run ANALYZE after a pg_dump
script has been restored.
ISTM that pg_dump should default to have ANALYZE statements for a table,
when both table definition and data are dumped. If only data (-a) or
only table definition (-s) is dumped the
Simon Riggs [EMAIL PROTECTED] writes:
There doesn't seem to be any reason to skip the ANALYZE, but I'll
implement it as an option.
-z on | off
--analyze=on | off
Only an aesthetic comment:
Short options don't usually take on/off arguments, I would suggest making the
default be to
On Mon, 2007-01-22 at 10:49 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
ISTM that pg_dump should default to have ANALYZE statements for a table,
when both table definition and data are dumped. If only data (-a) or
only table definition (-s) is dumped the default should be
On Mon, Jan 22, 2007 at 03:40:17PM +, Simon Riggs wrote:
This would add a table-specific ANALYZE statement following each table's
actions.
It'd probably be best to put it before any index creating activities,
since there's a better chance of everything from the table being in
shared
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Jan 22, 2007 at 03:40:17PM +, Simon Riggs wrote:
This would add a table-specific ANALYZE statement following each table's
actions.
It'd probably be best to put it before any index creating activities,
No, because then you'd fail to
