| From: | Andrew Biagioni <andrew(dot)biagioni(at)e-greek(dot)net> |
|---|---|
| To: | Iain <iain(at)mst(dot)co(dot)jp> |
| Cc: | 'Edoardo Ceccarelli' <eddy(at)axa(dot)it>, pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: R: slow seqscan after vacuum analize |
| Date: | 2004-02-05 16:23:34 |
| Message-ID: | 40226E06.2080701@e-greek.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Iain wrote:
>
>
>>Yes, you are right but it wasn't the case this time, I have run the
>>
>>
>explain plenty of
>
>
>>times with same results. I think that the reason was that I made a simple
>>
>>
>VACUUM,
>
>
>>after a VACUUM FULL ANALYZE (1h!!) things are ok
>>
>>
>
>It's reasonable to expect that a seq scan will perform faster after a full
>vacuum, as the physical size and organization of the table has been changed.
>
>I wouldn't expact a plain vacuum to have any tangible affect on performance,
>for the better or for the worse..
>
>
A plain VACUUM (without ANALYZE) will change the layout of the data
without refreshing the optimizer information, so that anything that DOES
use the optimizer will often be negatively affected; VACUUM ANALYZE
does a vacuum AND refreshes the optimizer information.
I usually run VACUUM ANALYZE on an hourly basis on our production
system, and it's fast enough and unobtrusive enough that I can't tell
that it's running (except by looking at the log, of course).
>I'd like to know more about the possibility of plain vacuums harming
>performance. This is the first I've heard of it. Vacuum full is not always
>an option in a production environment.
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 7: don't forget to increase your free space map settings
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Edoardo Ceccarelli | 2004-02-05 17:00:52 | R: R: slow seqscan after vacuum analize |
| Previous Message | Sam Barnett-Cormack | 2004-02-05 15:00:27 | Re: R: R: slow seqscan after vacuum analize |