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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to