Re: auto truncate/vacuum full
От
Tom Lane
Тема
Re: auto truncate/vacuum full
Дата
Msg-id
5915.1256676473@sss.pgh.pa.us
Ответ на
Re: auto truncate/vacuum full (Alvaro Herrera)
Список
Дерево обсуждения
auto truncate/vacuum full JC Praud <brutaltruth42@gmail.com>
Re: auto truncate/vacuum full Alvaro Herrera <alvherre@commandprompt.com>
Re: auto truncate/vacuum full Pavel Stehule <pavel.stehule@gmail.com>
Re: auto truncate/vacuum full Alvaro Herrera <alvherre@commandprompt.com>
Re: auto truncate/vacuum full Tom Lane <tgl@sss.pgh.pa.us>
Re: auto truncate/vacuum full Greg Smith <gsmith@gregsmith.com>
Re: auto truncate/vacuum full Tom Lane <tgl@sss.pgh.pa.us>
Re: auto truncate/vacuum full Greg Smith <gsmith@gregsmith.com>
Re: auto truncate/vacuum full Tom Lane <tgl@sss.pgh.pa.us>
Re: auto truncate/vacuum full JC Praud <brutaltruth42@gmail.com>
Re: auto truncate/vacuum full Alvaro Herrera <alvherre@commandprompt.com>
Re: auto truncate/vacuum full Jaime Casanova <jcasanov@systemguards.com.ec>
Re: auto truncate/vacuum full Tom Lane <tgl@sss.pgh.pa.us>
Re: auto truncate/vacuum full JC Praud <brutaltruth42@gmail.com>
Re: auto truncate/vacuum full Alvaro Herrera <alvherre@commandprompt.com>
Alvaro Herrera writes: > Now 40 mins walking those pages to figure out that they need to be > truncated, I concede that it's too much. Maybe we shouldn't be doing a > backwards scan; perhaps this breaks the OS readahead and make it even > slower. That's very possible, since a backwards scan is guaranteed to destroy any rotational positioning the OS has done --- you'll have to wait at least one disk rotation for each page, whereas a forward scan could hope to do better than that. Maybe we could do this along with my idea of incremental truncation. Scan the last K pages of the relation *forwards*, truncate as appropriate, repeat, until finding a nonempty page. Choosing the max value of K might be a bit tricky. regards, tom lane
В списке pgsql-general по дате отправления