I think sort by string column is lower during merge join, maybe comparing function in sort need be refined to save
somecycle. It’s the hot function when do sort.
Heikki Linnakangas <hlinnakangas@vmware.com>编写：
>On 01/27/2014 07:03 PM, Amit Kapila wrote:
>> I have tried to improve algorithm in another way so that we can get
>> benefit of same chunks during find match (something similar to lz).
>> The main change is to consider chunks at fixed boundary (4 byte)
>> and after finding match, try to find if there is a longer match than
>> current chunk. While finding longer match, it still takes care that
>> next bigger match should be at chunk boundary. I am not
>> completely sure about the chunk boundary may be 8 or 16 can give
>> better results.
>
>Since you're only putting a value in the history every 4 bytes, you
>wouldn't need to calculate the hash in a rolling fashion. You could just
>take next four bytes, calculate hash, put it in history table. Then next
>four bytes, calculate hash, and so on. Might save some cycles when
>building the history table...
>
>- Heikki
>
>
>--
>Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-hackers
