Martijn van Oosterhout <kleptog@svana.org> writes: > ISTM that row-wise comparisons, as far as indexes are concerned are > actually simpler than normal scan-keys. For example, if you have the > condition (a,b) >= (5,1) then once the index has found that point, > every subsequent entry in the index matches (except possibly NULLs). So > you really don't actually need a row-comparison at any point after > than.
Well, yeah you do, eg if the caller starts demanding backward fetch; you need to be able to tell where to stop. In any case it's certainly necessary to pass down the whole row-condition into the index AM; without that, the closest you could get would be an indexscan on a >= 5 which might have to scan an undesirably large number of rows before reaching the first one with b >= 1. > Now, if you have bracketing conditions like (a,b) BETWEEN (5,1) and > (7,0) it gets more interesting. Ideally you'd want to pass both of > these to the index so it knows when to stop. This really suggests using > your plan B since you then have the possibility of passing both, which > you don't really have with plan A. The latter also allows you to give > more auxilliary conditions like b>4. No, you misunderstood my plan A --- it's not giving up any of these options. But it's paying for it in complexity. I was envisioning a case like the above as being represented this way: sk_flags sk_attno sk_func sk_datum ROW_START a >= 5 ROW_END b >= 1 ROW_START a <= 7 ROW_END b <= 0 normal b > 4 Hence my comments about weird rules for the ordering of entries under plan A --- the normal and ROW_START entries would be in order by attno, but the row continuation/end entries wouldn't appear to follow this global ordering. They'd follow a local order within each row condition, instead. Since you didn't understand what I was saying, I suspect that plan A is too confusing ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq