| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Claudio Freire <klaussfreire(at)gmail(dot)com> |
| Subject: | Re: Tuplesort merge pre-reading |
| Date: | 2016-09-09 12:25:29 |
| Message-ID: | CAM-w4HPuQDr1UgowfBnnvJz0eWbgpHPU9JA6U_pRuT397XfFvg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Sep 9, 2016 at 1:01 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> I'm happy with what it looks like. We are in fact getting a more sequential
> access pattern with these patches, because we're not expanding the pre-read
> tuples into SortTuples. Keeping densely-packed blocks in memory, instead of
> SortTuples, allows caching more data overall.
Wow, this is really cool. We should do something like this for query
execution too.
I still didn't follow exactly why removing the prefetching allows more
sequential i/o. I thought the whole point of prefetching was to reduce
the random i/o from switching tapes.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2016-09-09 12:35:45 | Re: Push down more full joins in postgres_fdw |
| Previous Message | Simon Riggs | 2016-09-09 12:24:02 | Re: Bug in two-phase transaction recovery |