| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, JC Praud <brutaltruth42(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: auto truncate/vacuum full |
| Date: | 2009-10-27 20:47:53 |
| Message-ID: | 5915.1256676473@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-10-27 20:52:59 | Re: auto truncate/vacuum full |
| Previous Message | Greg Smith | 2009-10-27 20:40:25 | Re: auto truncate/vacuum full |