Thread: Simplifying pg_am representation of index sortability

With the just-committed changes in PathKey representation, the core
backend is now pretty well invested in the assumption that index AMs
that can deliver sorted results will use btree-compatible strategy
numbers for their order-related operators.  This doesn't seem to me
to be any huge limitation (a new AM might possibly define additional
operator strategies, but that needn't stop it from using 1-5 with
the same meanings as btree).  So I'm thinking that the pg_am columns
amorderstrategy and amdescorder are redundant and should be replaced
with a simple boolean, "amcansort" perhaps.  Any objections?
        regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> So I'm thinking that the pg_am columns amorderstrategy and amdescorder are
> redundant and should be replaced with a simple boolean, "amcansort" perhaps.
> Any objections?

Any chance of getting rid of the remaining inter-operator relationship columns
in pg_operator? At least for operator with btree strategy numbers oprcom and
oprnegate can be deduced. I think you already got rid of the rest. They are
quite a pain when defining cross-data-type operators.

I guess it's tricky since there may be operators which have valid negators and
commutators but which don't get used by any btree operator class. Does
Postgres actually make use of the oprcom and oprnegate in that case? Could
they be used only for such operators to provide values for when they can't be
automatically deduced?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com

On Sun, Jan 21, 2007 at 09:39:32AM +0000, Gregory Stark wrote:
> I guess it's tricky since there may be operators which have valid negators and
> commutators but which don't get used by any btree operator class. Does
> Postgres actually make use of the oprcom and oprnegate in that case? Could
> they be used only for such operators to provide values for when they can't be
> automatically deduced?

Sure, they're used whenever you have expressions of the form (CONST OP
VAR) or NOT(VAR OP CONST). This is basic expression simplification that
has little to do with b-trees in general.

You have operators like "contains" and "is contained by" which would be
opposites of eachother, but could never be used in a b-tree class.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Martijn van Oosterhout <kleptog@svana.org> writes:
> You have operators like "contains" and "is contained by" which would be
> opposites of eachother, but could never be used in a b-tree class.

A quick count shows that 46% of the entries in pg_operator that have an
oprcom link are not in any btree opclass.  For oprnegate the figure is a
bit lower (29%), but in any case getting rid of these columns would lose
a whole lot of information.

The specific reason that we have to have oprcom in particular is that
large parts of the executor want operators expressed the "right way
around": indexscan constraints have to be "indexcol op something" not
vice versa, merge and hash conditions have to be "outervar op innervar".
We could probably deduce what we need for merge and hash from the
opclasses (since those depend on the operators to be in btree and hash
classes respectively), but for indexes this would mean understanding the
operator interrelationships for every AM not only btree.  And I don't
think that's even possible for GIST or GIN because of their flexible
operator strategy numbering.

As for oprnegate, we'd lose the basic fact that = and <> are negators
because <> isn't a btree-indexable operator ...
        regards, tom lane