On Mon, Jun 21, 2004 at 10:28:59PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:

> > This is tricky because chunks are prepended to the queue, but it also
> > means we can stop processing as soon as a message belongs to another
> > transaction.
> AFAIR there isn't any essential semantics to the ordering of the queue
> entries, so you can probably get away with reordering if that makes life
> any easier.
> Also, rather than labeling each entry individually, it might be better
> to keep a separate list for each level of transaction.  Then instead of
> relabeling, you'd just concat the subtrans list to its parent's.  Seems
> like this should be faster and less storage.

Right, but it makes harder to detect when a duplicate relcache entry is
going to be inserted.  Judging from the commentary in the file this is
an issue.

Another idea I had was:
1. at subtransaction start, add a special "boundary" message carrying
the new Xid.
2. at subtransaction abort, process the first chunk backwards until the
boundary message with the corresponding Xid is found; if it's not, jump
to the next and repeat.

At subtransaction commit nothing special needs to be done.

This avoids having to label each message and to change the message
appending scheme.

Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"The eagle never lost so much time, as
when he submitted to learn of the crow." (William Blake)

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to