On Fri, Oct 15, 2010 at 5:35 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Oct 15, 2010 at 12:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> BTW, have we discussed the idea of embedding the role in the strategy
>> number? For example, require regular operators to have strategy
>> numbers 1-9999, while ordering operators have numbers 10000-19999,
>> leaving room for a couple more roles before we have to rethink the
>> assignment or widen amopstrategy to an int. That's a bit ugly but
>> might be better than adding a separate role column.
>
> Yeah, we talked about it.
>
> http://archives.postgresql.org/pgsql-hackers/2010-02/msg01075.php
> http://archives.postgresql.org/pgsql-hackers/2010-02/msg01079.php
Having said that, I'm not wild on having 5-key syscaches, even though
the patch is ready to go (modulo whatever rebasing is needed, which
probably isn't much). So if you can figure out a way to avoid it,
let's do that.
I still feel vaguely uneasy about the fact that the proposed patch
can't handle ASC/DESC or NULLS FIRST/LAST, and that unease grew a bit
more last night when I read Peter's patch to add collation support.
We could possibly cram ASC/DESC and NULLS FIRST/LAST in by defining
four new categories of operator strategies rather than one, but
there's no way that's going to work for collations. Is there some
other way to approach this problem? Can we leave pg_amop as it is,
and pass the context (sort vs. qual, ASC/DESC, NULLS FIRST/LAST,
collation, whatever...) to the index via some sort of side channel?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company