Re: ScanKey representation for RowCompare index conditions

Martijn van Oosterhout  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		>=		5ROW_END		b		>=		1ROW_START	a		<=		7ROW_END		b		<=		0normal		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