I think sort by string column is lower during merge join, maybe comparing function in sort need be refined to save some cycle. It’s the hot function when do sort.
Heikki Linnakangas <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
