Pinning a buffer that's already in the shared buffer cache is cheap, I doubt you're gaining much by keeping the private hash table in front of the buffer cache.
Yes, I see. Pinning a lot of buffers don't gives singnificant benefits but produce a lot of problems. Also removing the hash table can simplify code.
Also, it's possible that not all of the subtree is actually required during the emptying, so in the worst case pre-loading them is counter-productive.
What do you think about pre-fetching all of the subtree? It requires actual loading of level_step - 1 levels of it. I some cases it still can be counter-productive. But probably it is productive in average?
Well, what do you do if you deem that shared_buffers is too small? Fall back to the old method? Also, shared_buffers is shared by all backends, so you can't assume that you get to use all of it for the index build. You'd need a wide safety margin.
I assumed to check if there are enough of shared_buffers before switching to buffering method. But concurent backends makes this method unsafe.
There are other difficulties with concurrent backends: it would be nice estimate usage of effective cache by other backeds before switching to buffering method. If don't take care about it then we can don't switch to buffering method which it can give significant benefit.
------
With best regards,
Alexander Korotkov.
