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? When would it be
advantageous to create an index on the whole row anyway? Wouldn't the
key likely be excessively long? So why would we support this at all?
> I'm currently leaning to plan B, on the grounds that:
>
> 1. It would require no changes in _bt_checkkeys(), which is the only
> user of the data structure that is particularly performance-critical.
> With plan A we'd be adding at least a few cycles to _bt_checkkeys in
> all cases. Plan B avoids that at the cost of an extra level of function
> call to do a row comparison. Given the relative frequency of the two
> sorts of index conditions, this has to be the better tradeoff to make.
>
> 2. There's quite a bit of logic in btree indexscan setup that would find
> it convenient to treat a row comparison as if it were a single condition
> on just its leftmost column. This may end up being nearly a wash, but
> I think that plan A would make the setup code a shade more complex than
> plan B would. In particular, the rules about valid orderings of the
> ScanKey entries would be complicated under plan A, whereas under plan
> B it's still clear where everything belongs.
>
> Any thoughts? Anyone see a good plan C, or a serious flaw that I'm
> missing in either of these ideas?
That looks sound.
Best Regards, Simon Riggs
