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: | Raw Message | Whole Thread | 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 |