On Tue, Jan 1, 2019 at 10:41 AM Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > So, I have split this work into multiple patches. 0001 is a draft > version of some new infrastructure I'd like to propose, 0002 is the > thing originally described by the first two paragraphs in the first > email in this thread, and the rest I'll have to defer for now (the fd > passing stuff).
Apologies, there was a header missing from 0002, and a small change needed to a contrib file that I missed. Here is a new version. For the 0001 patch, I'll probably want to reconsider the naming a bit ("simple -> "specialized", "generic", ...?), refine (ability to turn off the small vector optimisation? optional MemoryContext? ability to extend without copying or zero-initialising at the same time? comparators with a user data parameter? two-value comparators vs three-value comparators? qsort with inline comparator? etc etc), and remove some gratuitous C++ cargo cultisms, and maybe also instantiate the thing centrally for some common types (I mean, perhaps 0002 should use a common uint32_vector rather than defining its own segnum_vector?). I suppose an alternative would be to use simplehash for the set of segment numbers here, but it seems like overkill and would waste a ton of memory in the common case of holding a single number. I wondered also about some kind of tree (basically, C++ set) but it seems much more complicated and would still be much larger for common cases. Sorted vectors seem to work pretty well here (but would lose in theoretical cases where you insert low values in large sets, but not in practice here AFAICS). -- Thomas Munro http://www.enterprisedb.com
0001-Add-parameterized-vectors-and-sorting-searching-s-v5.patch
Description: Binary data
0002-Refactor-the-fsync-machinery-to-support-future-SM-v5.patch
Description: Binary data