On Sat, Feb 13, 2010 at 3:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Just to be clear, I was intending this patch, at least, to be applied
>> now. I actually think there's a good argument that we should do at
>> least this much for 9.0, namely that now is probably the time when
>> there are the fewest outstanding patches that will be broken by this.
>> If we try to apply this for the first 9.1 CommitFest, then (1) it'll
>> have to be completely redone and (2) it'll force massive rebasing.
>
> What I think we should do is not change SearchSysCache for 9.0,
> but provide the SearchSysCacheN macros as syntactic sugar, and
> go around and change (at least most of) the call sites to use the
> macros. This is clearly cleaner source code, and with that method
> we'll still be ABI-compatible in 9.0 for anybody who doesn't fix their
> source right away.
Let me just think out loud for a second about the roadmap for knngist
at this point.
1. Add support for 5-key syscaches using either my patch or Teodor's
or some third version that may crop up. This could possibly be split
into one version that converts everything to using macros (for 9.0)
and a second version that actually increases the maximum number of
keys from 4 to 5 (for 9.1).
2. Modify pg_amop by adding a new column amopcategory, probably either
int2 or maybe even just char. Add this key to both unique indices on
pg_amop. Modify CREATE OPERATOR CLASS (and maybe ALTER OPERATOR
FAMILY?) to support some new syntax to add "order-by-op" operators to
opclasses/families (I'm thinking OPERATOR ORDER <strategy-number>
<operator> vs. the usual OPRATOR <strategy-number> <operator>). Also
add an amcanorderbyop flag to pg_am. Teach the planner to generate an
index scan path when amcanorderbyop is set on the AM and a suitable
order-by-op clause is present.
3. Modify GIST to use the infrastructure introduced by #2 for the new
<-> operator.
I'm not prepared to endorse doing #3 in core for 9.0, but I wonder if
it would be feasible to think about doing #1 and #2 and putting
something into contrib for #3. The last round of knngist patches had
a "planner" patch which basically did #2 (with the problems previously
discussed, to which we now seem to have a fairly clean and
straightforward solution) and then the "itself" and "proc" patches did
#3. The planner patch is actually quite small, so maybe it's not out
of the question to think that it might go in, with some suitable
fixing up along the lines discussed here and upthread.
On the other hand, maybe I'm getting too ambitious.
...Robert
