Thread

Re: Sequence Access Methods, round two

Michael Paquier <michael@paquier.xyz> — 2026-05-16T23:09:56Z

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