Re: VACUUM ANALYZE is faster than ANALYZE?
От | ktm@rice.edu |
---|---|
Тема | Re: VACUUM ANALYZE is faster than ANALYZE? |
Дата | |
Msg-id | 20120222153551.GN21114@aart.rice.edu обсуждение исходный текст |
Ответ на | Re: VACUUM ANALYZE is faster than ANALYZE? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, Feb 22, 2012 at 10:29:56AM -0500, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > On Tue, Feb 21, 2012 at 2:00 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > >> I had to reply to query about usage VACUUM ANALYZE or ANALYZE. I > >> expected so ANALYZE should be faster then VACUUM ANALYZE. > > > VACUUM ANALYZE scans the whole table sequentially. > > > ANALYZE accesses a random sample of data blocks. Random access is > > slower than sequential access, so at some threshold of sample size and > > sequential/random I/O speed ratio ANALYZE could become slower. > > That analysis is entirely wrong. In the first place, although ANALYZE > doesn't read all the blocks, what it does read it reads in block number > order. So it's not like there are "random" seeks all over the disk that > would not need to happen anyway. In the second place, VACUUM ANALYZE > consists of two separate passes, VACUUM and then ANALYZE, and the second > pass is going to be "random" I/O by your definition no matter what. > > If the filesystem is hugely biased towards sequential I/O for some > reason, and the VACUUM scan causes the whole table to become resident in > RAM where ANALYZE can read it "for free", then I guess it might be > possible to arrive at Pavel's result. But it would be an awfully narrow > corner case. I cannot believe that his statement is true in general, > or even for a noticeably large fraction of cases. > > regards, tom lane > Wouldn't a full sequential scan trigger the kernel read-ahead, which might not trigger for the analyze block reads, even though they are in order? That could account for the observation. Regards, Ken
В списке pgsql-hackers по дате отправления: