Re: Any justification for sequence table vs. native sequences? - Mailing list pgsql-general

From Tom Lane
Subject Re: Any justification for sequence table vs. native sequences?
Date
Msg-id 5030.1250631579@sss.pgh.pa.us
Whole thread Raw
In response to Re: Any justification for sequence table vs. native sequences?  (Bill Moran <wmoran@potentialtech.com>)
List pgsql-general
Bill Moran <wmoran@potentialtech.com> writes:
> And yes, it's pretty much guaranteed to be slower than built in sequences, with
> blocking when multiple threads want a sequence all at the same time.

It's also going to create a vacuum bottleneck unless the insert rate is
quite low, because each ID assignment will create another dead row in
the sequence management table.

> I'm rather concerned by the third column, as I'm not sure what his implementation
> approach is, and I'm concerned that he's using a home-brewed locking mechanism
> instead of using table locks.

Indeed, that looks a bit scary/pointless.  You could at least use
SELECT FOR UPDATE to lock the rows.

            regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: PL/PGSQL: why IF test the whole condition before failing or not?
Next
From: Alvaro Herrera
Date:
Subject: Re: index "pg_authid_rolname_index" is not a btree