| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: optimizing vacuum truncation scans |
| Date: | 2015-04-20 05:38:09 |
| Message-ID: | 553490C1.5010805@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 4/19/15 9:09 PM, Jeff Janes wrote:
> I did literally the simplest thing I could think of as a proof of
> concept patch, to see if it would actually fix things. I just jumped
> back a certain number of blocks occasionally and prefetched them
> forward, then resumed the regular backward scan. The patch and driving
> script are attached.
Shouldn't completely empty pages be set as all-visible in the VM? If so,
can't we just find the largest not-all-visible page and move forward
from there, instead of moving backwards like we currently do?
For that matter, why do we scan backwards anyway? The comments don't
explain it, and we have nonempty_pages as a starting point, so why don't
we just scan forward? I suspect that eons ago we didn't have that and
just blindly reverse-scanned until we finally hit a non-empty buffer...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2015-04-20 06:31:30 | Re: alternative compression algorithms? |
| Previous Message | Jeff Janes | 2015-04-20 05:13:37 | Re: PATCH: adaptive ndistinct estimator v4 |