On Sat, Feb 13, 2010 at 3:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
