On Fri, Sep 02, 2005 at 10:31:45AM -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > If I get a plan like this, what will actually be performed if EXPLAIN
> > shows this:
>
> > Sort (cost=12.90..12.91 rows=1 width=207)
> > Sort Key: log_actionseq
> > -> Index Scan using sl_log_1_idx2_hu, sl_log_1_idx2_hu,
> > sl_log_1_idx2_hu, sl_log_1_idx2_hu on sl_log_1 (cost=0.00..12.89 rows=1
> > width=207)
> > Index Cond: (
> > ((log_xid < '1349053093') AND (log_xid >= '1349052761'))
> > OR ((log_xid < '1349053093') AND (log_xid >= '1349052761'))
> > OR ((log_xid < '1349053093') AND (log_xid >= '1349052761'))
> > OR ((log_xid < '1349053093') AND (log_xid >= '1349052761'))
> > )
>
> > Will the same range be scanned 4 times ?
>
> Yes. However, I don't understand how you got that result; AFAIK the
> planner should have eliminated the duplicate subclauses.
Maybe it has to do with the xxid datatype Slony-I adds; maybe it's
missing some operator or property.
I wonder why we don't support more operators on Xid, so these things are
avoided? Right now we only have =, AFAIR.
--
Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com
"Hay quien adquiere la mala costumbre de ser infeliz" (M. A. Evans)
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
