Nuno Santos wrote:

>Hello.
>
>I'm trying to improve the time it takes to add a new table to an
>existing set. With 3 replicas, all in the same host, it is taking close
>to 10 seconds to add a new table. I suspect the problem is with all the
>WAIT FOR EVENT commands I'm issuing during the creation script. The
>documentation is not totally clear about when it is necessary to wait
>for the previous event to be processed, so I don't know if I can remove
>some waits. Could anyone give me some hints about which are really
>necessary? For instance, is it necessary to wait between the subscribe
>set commands?
>
>My script is the following:
>
>cluster name = cluster;
>node 1 admin conninfo = 'host=localhost dbname=db1 user=postgres;
>node 2 admin conninfo = 'host=localhost dbname=db2 user=postgres;
>node 3 admin conninfo = 'host=localhost dbname=db3 user=postgres;
>create set (id=4, origin=1, comment='Temp set');
>WAIT FOR EVENT (ORIGIN = ALL, CONFIRMED = ALL, WAIT ON = 1);
>set add table (set id=4, origin=1, id=6, fully qualified name =
>'public.dir17', comment='dir17');
>WAIT FOR EVENT (ORIGIN = ALL, CONFIRMED = ALL, WAIT ON = 1);
>subscribe set ( id = 4, provider = 1, receiver = 2, forward = yes);
>WAIT FOR EVENT (ORIGIN = ALL, CONFIRMED = ALL, WAIT ON = 1);
>subscribe set ( id = 4, provider = 1, receiver = 3, forward = yes);
>WAIT FOR EVENT (ORIGIN = ALL, CONFIRMED = ALL, WAIT ON = 1);
>merge set ( ID = 1, ADD ID = 4, ORIGIN = 1 );
>
>
>  
>
I would be inclined to take out the WAIT FOR EVENTs that occur before
the SUBSCRIBE SET requests, but not any of the subsequent ones.

>I have another related question. If I send two commands before waiting
>for an event, is the wait guaranteed to return only when both events
>were processed? For instance:
>
>subscribe set ( id = 4, provider = 1, receiver = 2, forward = yes);
>subscribe set ( id = 4, provider = 1, receiver = 3, forward = yes);
>WAIT FOR EVENT (ORIGIN = ALL, CONFIRMED = ALL, WAIT ON = 1);
>merge set ( ID = 1, ADD ID = 4, ORIGIN = 1 );
>
>I know that Slonik only waits for the previous event, but since the
>subscribe events are issued on the same node, aren't they ordered, so
>that it is enough to wait for the last one?
>  
>
That seems right.

The thing is, the SUBSCRIBE SET events likely run for long enough that
any time "wasted" by waits should be pretty immaterial there.  Waiting a
few seconds for event propagation after a SUBSCRIBE SET that took 20
minutes doesn't strike me as a problem.

What I wouldn't do is to put WAIT FOR EVENT after each of the operations
that modify sets, thus, CREATE SET, SET ADD TABLE, SET ADD SEQUENCE, and
such...