On 4/25/07, Christopher Browne <cbbrowne at ca.afilias.info> wrote:
>
> >"Most of the time, it isn't" implies that some of the time it is.
>
> No, it *doesn't* imply that the order is known to matter.


I apologize for being casual in my use of the language. Allow me to
rephrase:

"Most of the time it isn't" _suggests_ that some of the time it is. Hence
this thread.

What I meant when I wrote that is that "most of the time, there is *no*
> significance whatsoever to the ordering of the tables."  And I had no
> certainty of significance that I could attach to the remainder.
>
> In a more or less mathematical sense, most of the time, table IDs are
> not taken into *any* kind of consideration.  Most of the time, the slon
> sits there applying SYNC events, and the queries that are used for that
> do not order themselves based on table ID.  They are ordered based on
> "action sequence" (there's a sequence that gives out an "action
> sequence" value each time the logtrigger() function fires).  I can say,
> with some authority, that SYNC events do not make any use of table ID
> ordering.  So, for that "most of the time," table ID order forcibly
> *can't* matter, because it is not even considered.


Right. That makes sense to me.

There are certain events that *consider* table ID ordering.  Notably,
> SUBSCRIBE SET (when it does the initial COPY), and EXECUTE SCRIPT.
> These events do their work, table by table, in an order controlled by
> the table IDs within the set.
>

So, the only contexts in which table id ordering _may_ matter are SUBSCRIBE
SET and EXECUTE SCRIPT.


> It is a bit of an open question as to whether there is reason to expect
> there to be any significance to whether one table is processed *before*
> another, or *after.*  There might be some significance in the context of
> a set of replicated tables that involve inheritance relationships,
> although I haven't seen any evidence yet of any *known* significance,
> even in that case.  I haven't been able to rule it out, which is why I
> haven't been able to make any certain statement to the effect that "we
> know that table ID ordering DOES NOT MATTER."
>
> If someone's doing something bizarre enough, there may be some
> interaction where it will matter.  I'd be plenty interested in hearing
> about such a case; that should provide enough information to come up
> with a more categorical statement about where it does and doesn't matter.


Agreed, that'd be interesting to see.

Until then, it has to remain with just a little bit of uncertainty.  I
> don't know if P=3DNP.  And I don't know for certain that table ID ordering
> is of NO significance.
>

So should we update the documentation about this? ISTM that the current
wording _suggests_ there's an issue when as far as we can tell there isn't.
Instead why don't we say that table id's can be arbitrary and provide a
footnote to the effect that we're pretty sure this is the case, but haven't
managed to prove it yet. Maybe even go so far as to mention we have funny
suspicions about interaction with inherited tables, but that they're just
speculative at this point.

It seems silly to encourage people to adopt a particular ordering when
1) we have no evidence to demonstrate that ordering matters
2) we haven't identified even a theoretical failure case that is based on
ordering
3) we can't reasonably believe that a given ordering is superior for
avoiding an unknown issue

We'd look especially silly if it did matter, and the order we've been
endorsing is the wrong one.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20070425/=
b92574b2/attachment.htm