On 09/16/2016 03:18 AM, Amit Kapila wrote:
Attached is a run with 1000 rows.
I think 1000 is also less, you probably want to run it for 100,000 or
more rows. I suspect that the reason why you are seeing the large
difference between btree and hash index is that the range of values is
narrow and there may be many overflow pages.
Attached is 100,000.
I think for CHI is would be Robert's and others feedback. For WAL, there is
[1].
I have fixed your feedback for WAL and posted the patch.
Thanks !
I think the
remaining thing to handle for Concurrent Hash Index patch is to remove
the usage of hashscan.c from code if no one objects to it, do let me
know if I am missing something here.
Like Robert said, hashscan.c can always come back, and it would take a
call-stack out of the 'am' methods.
Best regards,
Jesper
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
