pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedpg_restore followed by immediate VACUUM ANALYZE
4+ messages / 2 participants
[nested] [flat]
* pg_restore followed by immediate VACUUM ANALYZE
@ 2009-12-01 03:46 Bryce Nesbitt <bryce2@obviously.com>
2009-12-01 03:55 ` Re: pg_restore followed by immediate VACUUM ANALYZE Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 4+ messages in thread
From: Bryce Nesbitt @ 2009-12-01 03:46 UTC (permalink / raw)
To: pgsql-sql
I looking at a script that does a pg_restore followed by an immediate
VACUUM ANALYZE (postgres 8.3).
I'm told that without the VACUUM ANALYZE the database will run slow.
Does this ring true?
Does pg_restore not update the query planner statistics?
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pg_restore followed by immediate VACUUM ANALYZE
2009-12-01 03:46 pg_restore followed by immediate VACUUM ANALYZE Bryce Nesbitt <bryce2@obviously.com>
@ 2009-12-01 03:55 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-12-01 03:59 ` Re: pg_restore followed by immediate VACUUM ANALYZE Bryce Nesbitt <bryce2@obviously.com>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2009-12-01 03:55 UTC (permalink / raw)
To: Bryce Nesbitt <bryce2@obviously.com>; +Cc: pgsql-sql
Bryce Nesbitt <bryce2@obviously.com> writes:
> I looking at a script that does a pg_restore followed by an immediate
> VACUUM ANALYZE (postgres 8.3).
That's standard.
> Does pg_restore not update the query planner statistics?
Correct. Autovacuum might fix them eventually, but usually it's
worth forcing the issue once you've completed your data loading.
(This might involve multiple steps, which is why pg_restore
doesn't try to force it for you.)
regards, tom lane
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pg_restore followed by immediate VACUUM ANALYZE
2009-12-01 03:46 pg_restore followed by immediate VACUUM ANALYZE Bryce Nesbitt <bryce2@obviously.com>
2009-12-01 03:55 ` Re: pg_restore followed by immediate VACUUM ANALYZE Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-12-01 03:59 ` Bryce Nesbitt <bryce2@obviously.com>
2009-12-01 04:04 ` Re: pg_restore followed by immediate VACUUM ANALYZE Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 4+ messages in thread
From: Bryce Nesbitt @ 2009-12-01 03:59 UTC (permalink / raw)
To: pgsql-sql
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tom Lane wrote:<br>
<blockquote cite="mid:19189.1259639712@sss.pgh.pa.us" type="cite">
<blockquote type="cite">
<pre wrap="">Does pg_restore not update the query planner statistics?
</pre>
</blockquote>
<pre wrap=""><!---->
Correct. Autovacuum might fix them eventually, but usually it's
worth forcing the issue once you've completed your data loading.
(This might involve multiple steps, which is why pg_restore
doesn't try to force it for you.)</pre>
</blockquote>
Hmm. It seems like pg_restore would already know 90% of what it needs
to in this case.<br>
Of course I'm just trying to cut down on the 4+ hour VACUUM ANALYZE.
But thanks for<br>
the note, I'll look elsewhere for speed improvements.<br>
</body>
</html>
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pg_restore followed by immediate VACUUM ANALYZE
2009-12-01 03:46 pg_restore followed by immediate VACUUM ANALYZE Bryce Nesbitt <bryce2@obviously.com>
2009-12-01 03:55 ` Re: pg_restore followed by immediate VACUUM ANALYZE Tom Lane <tgl@sss.pgh.pa.us>
2009-12-01 03:59 ` Re: pg_restore followed by immediate VACUUM ANALYZE Bryce Nesbitt <bryce2@obviously.com>
@ 2009-12-01 04:04 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 4+ messages in thread
From: Tom Lane @ 2009-12-01 04:04 UTC (permalink / raw)
To: Bryce Nesbitt <bryce2@obviously.com>; +Cc: pgsql-sql
Bryce Nesbitt <bryce2@obviously.com> writes:
>> Correct. Autovacuum might fix them eventually, but usually it's
>> worth forcing the issue once you've completed your data loading.
>> (This might involve multiple steps, which is why pg_restore
>> doesn't try to force it for you.)</pre>
> Hmm. It seems like pg_restore would already know 90% of what it needs
> to in this case.<br>
But of course pg_restore doesn't know what else you might want to do.
> Of course I'm just trying to cut down on the 4+ hour VACUUM ANALYZE.
You could try just ANALYZE without the VACUUM.
regards, tom lane
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2009-12-01 04:04 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-12-01 03:46 pg_restore followed by immediate VACUUM ANALYZE Bryce Nesbitt <bryce2@obviously.com>
2009-12-01 03:55 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-12-01 03:59 ` Bryce Nesbitt <bryce2@obviously.com>
2009-12-01 04:04 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox