without looking why VIEWs do the check multiple times, only about the proposed patch - for a short list, the STL map will be slower due to necessary allocations for temporary objects, and O(N^2) search like today would beat O(N*logN) in proposed patch. I'd guess, in most cases those Lists are tiny.

Good point, had only huge lists in mind, though for short-lists i guess the difference of using STL maps compared to a nested loop will be in micro-secs.
Anyway will test that and maybe modify proposed patch.

So i've done extensive testing and optimizations for the map lookups see attached test-patch.

You're right that for short-lists the performance is lower compared to the original implementation
but the difference is in fact within a few microseconds.
I.e. for 10 elements the difference is just 5µs.

Starting with 70-90 elements performance of the lookup begins to be better than the original implementation.
For 4k elements the nested while-loop needs 78568µs and the map 1389µs which is a significant improvement.

These numbers are not representative as i tested it with a single linux-machine only but it shows that
there is an improvement.

I do understand that for OLTP use-cases a number of 4000 elements/columns per view makes no sense
but for denormalized OLAP/datawarehouse scenarios it is quite common to have hundrets of columns for performance reasons.

To avoid minimal performance loss in OLTP scenarios the map-function will be used only if the threshold of 100 elements is exceeded.

Yes, hybrid approach (O(N^2) for small list, O(N*logN) for large ones) is probably better that either one