On T, 2005-09-27 at 15:27 -0400, Jan Wieck wrote:
> On 9/27/2005 3:08 PM, Christopher Browne wrote:
> > 
> > We have just been able to successfully point at a Probably Really Good
> > answer to this; it just got checked into CVS HEAD and 1_1_STABLE...
> > 
> > Let me suggest that you create an extra index:
> > 
> > create index sl_log_1_idx2 on _pl_replication.sl_log_1(log_xid
> > _pl_replication.xxid_ops);
> 
> Is that an optimization problem introduced by using BETWEEN instead of 
> the excessive OR chains?

No, the original index is worse than useless in case the node is master
for more than one set which are subscribed to same subscriber, at least
on pg 7.4, maybe others.

By "worse than useless" I mean that postgres will perform an *indexscan*
on the first field (which is *constant*) of the three field index, which
is even slower than seqscan.

In one set per master case the plan uses two first fields and is
reasonably fast. The 3rd field is never used (ok, in case there is
exactly one xid it can be used for ordering).

-- 
Hannu Krosing <hannu at skype.net>