Shared lock access when reading metadata during scans is slow

[benjaminwinger]

A major performance issue with #2304 is reading metadata too frequently, and while the number of calls is the main issue (fortunately easily resolvable), roughly 75% of the overhead is just from locking, despite the high cost being observed in read-only scans where nothing should be locking it for writing (removing the lock sped up one test from ~300ms to ~70ms).
There are probably more efficient lock implementations we can use.

[ray6080]

Optimistic locks should work here. I would give a try on that first. This perhaps can be optimized together with changes to the hash index.

[benjaminwinger]

The cost was vastly reduced (down to 0.05% of the new, much lower runtime) by removing the extra calls (from multiple metadata reads per string to one per call to Column::scan, i.e. one per 2048 values). I suspect that there is enough contention in the locks that having many threads trying to acquire even the shared lock very frequently slowed things down a lot.

[Riolku]

Temporary plan is to keep the existing code. It doesnt seem like there are other RwLock implementations out there (aside from maybe boost?) and we can probably find better ways to get speed improvements than shooting ourselves in the foot with more complex concurrency.