feat: performance improvements

[cristianmtr]

Closes #6

Results before this PR:

indexing 1000 takes 0 seconds (0.22s)
rolling update 3 replicas x 2 shards takes 0 seconds (0.82s)
search with 10 takes 0 seconds (0.23s)

indexing 10000 takes 0 seconds (0.75s)
rolling update 3 replicas x 2 shards takes 9 seconds (9.08s)
search with 10 takes 0 seconds (0.22s)

indexing 100000 takes 7 seconds (7.59s)
rolling update 3 replicas x 2 shards takes 7 minutes and 17 seconds (437.44s)
search with 10 takes 0 seconds (0.22s)

---

RESULTS NOW

indexing 1000 takes 0 seconds (0.44s)                                                                                   
rolling update 3 replicas x 2 shards takes 0 seconds (0.81s)

indexing 10000 takes 1 second (1.01s)                                                                                   
rolling update 3 replicas x 2 shards takes 2 seconds (2.63s)

indexing 100000 takes 8 seconds (8.10s)                                                                                 
rolling update 3 replicas x 2 shards takes 3 minutes and 27 seconds (207.14s)

MORE BENCHMARKING

indexing 500000 takes 30 seconds (30.07s)    
rolling update 3 replicas x 2 shards takes 26 minutes and 57 seconds (1617.99s)
search with 10 takes 0 seconds (0.21s)

[davidbp]

LGTM

[numb3r3]

So, the performance improvement is achieved by reducing the values of ef_construct and max_connection, right?

[cristianmtr]

So, the performance improvement is achieved by reducing the values of ef_construct and max_connection, right?

No. It's about the batching during .sync_index

[makram93]

Just a small change w.r.t traversal_paths parameter: https://github.com/jina-ai/executor-hnsw-postgres/runs/4264564015?check_suite_focus=true#step:8:163

[cristianmtr]

@makram93 I will address the trav path in another PR