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: | Raw Message | Whole Thread | 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 |