Re: ScanKey representation for RowCompare index conditions

Simon Riggs <simon@2ndquadrant.com> writes:
> On Sun, 2006-01-15 at 18:03 -0500, Tom Lane wrote:
>> There's one nontrivial decision still to make about how to implement
>> proper per-spec row-comparison operations, namely: how a row
>> comparison ought to be represented in the index access method API.

> I'm not sure I understand why. Surely a row wise comparison can take
> advantage of indexes on some of its columns?

Not until we write the code to let it do so.  Currently, what the system
can match to an index on (a,b) is conditions like WHERE a >= x AND b >= y,
which is quite a different animal both semantically and representationally
from WHERE (a,b) >= (x,y).  (At least, assuming that one imputes the
correct SQL-spec meaning to the latter, viz a > x OR (a = x AND b >= y).)
Because of the semantic difference, we have to preserve the difference
when passing the condition to the index AM, thus the need for my
question.

> So why would we support this at all?

Example applications here and here:
http://archives.postgresql.org/pgsql-performance/2004-07/msg00188.php
http://archives.postgresql.org/pgsql-performance/2005-12/msg00590.php
(which demonstrate BTW the reasons for not trying to handle this by just
expanding out the OR/AND equivalents).
        regards, tom lane