Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead

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?

In response to

Browse pgsql-hackers by date

  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