On Fri, May 15, 2026 at 11:04:37AM +0200, Andrei Lepikhov wrote: > Here is a rebased version of the patch set. > It is generally looks quite elegant. Of course, an int64 value seems a little > restrictive, but in practice, with four different algorithms on board, I don't > need a value larger than 64 bits at this moment.
Neither do I. Note that I have dropped this patch set from the commit fest as I was/still-am not sure about its future, and there is a lack of enthusiasm around it. > Notes on the snowflake sequence (0007): > 1. The gettimeofday() might be called out of the loop before the exclusive > lock > is acquired. > 2. At least in my experience, gettimeofday does not always return > monotonically > increased values. So, it makes sense to save the used value inside the 'seq' > structure and, if gettimeofday returned an earlier value, just increase this > cached value a little. > 3. Sleep call under the lock. It might not be so inevitable, and call it only > when the time value stays the same. That's the last patch of the series. This can be tweaked infinitely with the right API infrastructure in place. One thing that I have been pondering about is a worst-case scenario with a benchmark that could show a performance impact due to the function pointers: - Mount PGDATA on a tmpfs. - Disable fsync, etc. - Create a table with a bunch of attributes, with one sequence attached to each as default. - COPY FROM to trigger a bunch of computations over all the attributes. - Single backend, to avoid buffer lock interference. - Disable WAL, trick the code to not WAL-logged, or use an in-memory AM. -- Michael
signature.asc
Description: PGP signature
