"Tom Lane" <[EMAIL PROTECTED]> wrote
> No, that's completely irrelevant to his problem.  The reason we can't do
> this is that the transformation from "x << const" to a range check on x
> is a plan-time transformation; there's no mechanism in place to do it
> at runtime.  This is not easy to fix, because the mechanism that's doing
> it is primarily intended for LIKE/regex index optimization, and in that
> case a runtime pattern might well not be optimizable at all.

Not quite understand, sorry ...

(1) For this query (in an as-is PG syntax, which find out all rectangles lie 
in a given rectangle) :

SELECT r FROM all_rectangles
  WHERE r << rectangle('(1,9),(9,1)');

If there is a GiST/Rtree index associated with all_rectangles.r, how do 
optimizer estimate the cost to decide that we should use this index or 
not(then by a seqscan)?

(2) Does your above explaination mean that we can't use GiST for a spatial 
join operation?


---------------------------(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

Reply via email to