From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | mlw <pgsql(at)mohawksoft(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: analyze after a database restore? |
Date: | 2003-02-27 20:12:36 |
Message-ID: | 27615.1046376756@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
mlw <pgsql(at)mohawksoft(dot)com> writes:
> From an "ease of use" perspective, it would be one less step.
There is something to be said for that. As Rod notes, this has been
considered and rejected before --- but I think that was back when
ANALYZE (a) could only be done as part of VACUUM, and (b) insisted on
scanning the whole table. The current implementation is vastly
lighter-weight than what we were looking at back then. Perhaps it's
time to reconsider.
Although I suggested doing a single unconditional ANALYZE at the end
of the script, second thought leads me to think the per-table ANALYZE
(probably issued right after the table's data-load step) might be
better. That way you'd not have any side-effects on already-existing
tables in the database you are loading to. OTOH, that way would leave
the system catalogs un-analyzed, which might be bad.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Marshall | 2003-02-27 22:10:01 | Re: Free-space-map management thoughts |
Previous Message | Rod Taylor | 2003-02-27 20:07:50 | Re: Can pessimistic locking be emulated? |