On Thu, Mar 30, 2017 at 7:23 PM, Robert Haas <robertmh...@gmail.com> wrote: > I think approach B is incorrect. Suppose we have 1536 buckets and > hash values 2048, 2049, 4096, 4097, 6144, 6145, 8192, and 8193. If I > understand correctly, each of these values should be mapped either to > bucket 0 or to bucket 1, and the goal of the sort is to put all of the > bucket 0 tuples before all of the bucket 1 tuples, so that we get > physical locality when inserting. With approach A, the sort keys will > match the bucket numbers -- we'll be sorting the list 0, 1, 0, 1, 0, > 1, 0, 1 -- and we will end up doing all of the inserts to bucket 0 > before any of the inserts to bucket 1. With approach B, we'll be > sorting 512, 513, 1024, 1025, 0, 1, 512, 513 and will end up > alternating inserts to bucket 0 with inserts to bucket 1.
Oops sorry, yes 2 denominators are different (one used in an insert and another used in sorting keys) we will end up with different bucket numbers. I think in patch B, I should have actually taken next 2-power number of 1536 as the denominator and try to get the mod value. If the mod value is > 1536 then reduce the denominator by half and retake the mod to get the bucket within 1536. Which is what effectively Patch A is doing. Approach B is a blunder, I apologize for that mistake. I think Patch A should be considered. If adding the members of struct Tuplesortstate is a concern I will rewrite Patch B as said above. -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers