Reduce critical section on inserts

[Ngalstyan4]

Currently we hold a lock on the header page of the index for much much longer than necessary on insertions.

• Benchmark this and see if concurrent inserts will achieve significantly higher throughput if we move to more granular locking
• Implement more granular locking- lock the header page to only create necessary new pages and then use fine grained locking for the rest of modifications

[ezra-varady]

Could this be at play in #221?

[broccoliSpicy]

after reading a few postgres source code and documentations,
GenericXLogRegisterBuffer(),
GenericXLogFinish()
I think we can UnlockReleaseBuffer(hdr_buf); right after hdr_page = GenericXLogRegisterBuffer(state, hdr_buf, LDB_GENERIC_XLOG_DELTA_IMAGE); since GenericXLogRegisterBuffer will copy the hdr_buf contents.

code:
insert.c
code diff

However, I couldn't see any performance improvement in this modified code during the concurrent insertion.

postgres is just not using the lantern extension concurrently

the python script for concurrent insertion(modified using Varik's https://gist.github.com/var77/dbf9b8c9845356d51a5588f6c7020cd1)

some primitive benchmark results:
the original code:
Concurrent insertion (10 concurrent insertion tasks)

Concurrent insertion (4 concurrent insertion tasks)

After critical section shorten:
Concurrent insertion (10 concurrent insertion tasks)

Concurrent insertion (4 concurrent insertion tasks):

my postgres setting:

my data set:
wget https://storage.googleapis.com/lanterndata/openai/openai_wikipedia_emb_arr_100k.csv -O ~/wiki100.csv

there is something I am missing here

[Ngalstyan4]

You have to be careful here, as the header must remain under lock as long as there is a chance we will modify it.
When we release the lock, someone else may come and modify it, in which case our copy becomes stale.

I think there still is lock contention around modifying blockmap pages. Consecutive inserts will try to modify consecutive blockmap pages resulting in lock contention similar to the one you removed in the diff above.

I have not looked into optimizing those since the whole concept of blockmaps will go away in a future release.

[broccoliSpicy]

I was under the impression that the header is also a log structure, I guess this was wrong.
I actually don't know much blockmaps in lantern and postgres.

[Ngalstyan4]

Thanks so much for looking into this, though!
Feel free to reach out to me via email at my name at lantern dot dev directly, in case there are ways we can unblock you as you go through the codebase

re: blockmaps:
It is a lantern concept and is not very well documented. There is a lantern index diagram here that has some details around it, in case it is useful.

[broccoliSpicy]

Thanks so much for looking into this, though! Feel free to reach out to me via email at my name at lantern dot dev directly, in case there are ways we can unblock you as you go through the codebase

re: blockmaps: It is a lantern concept and is not very well documented. There is a lantern index diagram here that has some details around it, in case it is useful.

I actually don't have access to this diagram haha, that's fine

[Ngalstyan4]

inline image below:

[broccoliSpicy]

inline image below:

thanks so much!