| From: | Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead |
| Date: | 2015-07-24 09:53:09 |
| Message-ID: | CAP-rdTYEBxtm2H_JcA7_VtOYEeo9jT2Af9KnfmEW9o_sRRoB7Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2015-07-24 Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>:
> Especially useful would be to know whether interleaving a small number
> of TID ordered streams (as would probably be generated by parallel
> scans/processing) would result in an ordering that performs
> significantly worse or not. I assume (but cannot prove) that in this
> case the OS will understand the read pattern as being multiple streams
> and prefetching will work correctly.
OTOH, that is probably only true when there are a large number of
duplicate keys. Otherwise the order within each (small) group will
appear random, which may or may not result in a significant
performance drop. This probably also depends on whether fadvise (or
friends) are used.
Nicolas
--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-07-24 09:58:04 | Re: Free indexed_tlist memory explicitly within set_plan_refs() |
| Previous Message | Nicolas Barbier | 2015-07-24 09:49:36 | Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead |