Re: Sequence Access Method WIP

On 19/03/16 23:02, Alvaro Herrera wrote:
> Petr Jelinek wrote:
>
>> And finally the 0003-gapless-seq is example contrib module that implements
>> dependably and transitionally safe gapless sequence access method. It's
>> obviously slow as it has to do locking and basically serialize all the
>> changes to sequence so only one transaction may use it at a time but it's
>> truly gapless. It also serves as an example of use of the api and as a test.
>
> I'm trying to figure out this one, and I think I found something very
> surprising. This code contains this
>
> +#define GAPLESS_SEQ_NAMESPACE "gapless_seq"
> +#define VALUES_TABLE_NAME "seqam_gapless_values"
>
> which as far as I understand is something like a side table where values
> for all the sequences are stored. Is that right? If it is, I admit I
> didn't realize that these sequences worked in this way. This seems
> broken to me. I had been under the impression that the values were
> always stored in the sequence's relation. Maybe I'm misunderstanding;
> please explain how this works.
>

Yes, I did explain in the original submission that added gapless
sequence, which is about million messages upthread so it's
understandable that it's hard to follow.

The sequence am API is non-transactional (and does not use MVCC) as
sequences are non-trasactional and this provides significant performance
boost. But the gapless sequence needs to handle things like
subtransactions and rollbacks so it needs MVCC, for this reasons it also
uses external table to handle that, the locking and stuff is still
handled using normal sequence api but the MVCC part is handled by side
table yes.

Just as a note to you and anybody who wasn't following in the beginning
of this quite long thread - one of the goals of the sequence am api was
to abstract the actual storage and WAL logging of the sequences away
from the extension, so there is no generic WAL or anything like the
index am provides here. At this point though, it might be worth
reevaluating that approach if the generic WAL gets in.

>
> FWIW I find it annoying that this submission's 0001 patch and
> Alexander's 0001 have so much in common, yet they aren't similar enough
> to consider that either is the definite form. Also, you have the SGML
> docs for CREATE ACCESS METHOD in 0002 instead of 0001, so comparing both
> versions isn't trivial.

Well it's relatively annoying for the patch author as well. I tried to
write it so that it's as easy to merge as possible - the common code is
in my 0001, except for the SQL (gram.y, docs) because the SQL does not
have any meaning until either indexam or seqeunceam gets in (which also
makes it impossible to submit as separate infrastructure patch, because
there is no point of having the code in without the stuff that either
indexam or sequenceam provides on top of it).

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services