| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Memory prefetching while sequentially fetching from SortTuple array, tuplestore |
| Date: | 2015-09-03 04:50:54 |
| Message-ID: | CAM3SWZTn8BZ27JESp24i-pdmAD81FWB44FhtimRbzb6hezM0ug@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 2, 2015 at 9:43 PM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> Peter, would you be able to share the test case which you saw the speedup
> on. So far I've been unable to see much of an improvement.
The case I tested was an internal sort CREATE INDEX. I don't recall
the exact details, but testing showed it to be a fairly robust
speedup. It was not a very brief CREATE INDEX operation, or a very
lengthily one. trace_sort output made it quite visible that there was
a significant saving after the sort is "performed", but before it is
"done". It wasn't hard to see an improvement on a variety of other
cases, although the Intel vTune tool made the difference particularly
obvious.
The only thing that definitely won't be helped is pass-by-value datum
sort cases. In case it matters, I used GCC 4.8.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2015-09-03 05:22:26 | Re: Foreign join pushdown vs EvalPlanQual |
| Previous Message | David Rowley | 2015-09-03 04:43:02 | Re: Memory prefetching while sequentially fetching from SortTuple array, tuplestore |