Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead - Mailing list pgsql-hackers

From Nicolas Barbier
Subject Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead
Date
Msg-id CAP-rdTYEBxtm2H_JcA7_VtOYEeo9jT2Af9KnfmEW9o_sRRoB7Q@mail.gmail.com
Whole thread Raw
In response to Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead  (Nicolas Barbier <nicolas.barbier@gmail.com>)
List pgsql-hackers
2015-07-24 Nicolas Barbier <nicolas.barbier@gmail.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?



pgsql-hackers by date:

Previous
From: Nicolas Barbier
Date:
Subject: Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead
Next
From: Andres Freund
Date:
Subject: Re: Free indexed_tlist memory explicitly within set_plan_refs()