On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >>> Well, if you were willing to change pg_amop so that the key was >>> (amopfamily, amoplefttype, amoprighttype, amopcategory) rather than >>> just (amopfamily, amoplefttype, amoprighttype), the issue of what to >>> do if an operator can be in more than one category becomes moot. You >>> just specify the operator more than once if need be. > > Yeah, that occurred to me too after sending my earlier email. > >> Except I'm full of it, because amopstrategy is in there too. Hmm. >> And that's unfortunate because the syscache machinery is limited to >> four columns as lookup keys. > > Ugh. Still, we could certainly change the 4-key limit to 5, though it > might be a tad tedious to go round and edit all the SearchSysCache and > related calls. Maybe while we were at it we should change them to > SearchSysCache1, SearchSysCache2, etc to not have the limit hardwired > textually in quite so many places...
Maybe. It sounds sort of awful though; and there's probably a distributed performance penalty involved >> This is a bit ugly, but one idea that occurs to me is to change >> amopstrategy from int16 to int32. Internally, we'll treat the low 16 >> bits as the strategy number and the high 16 bits as the strategy >> category, with strategy category 0 being "index search qualifier". > > Hm, yeah that would work, but I agree it's ugly. On further review there's a serious problem with this idea: pg_amop_opr_fam_index. > While thinking about different possible solutions here: one of the > things that was worrying me is that for cases where the same operator > can serve in more than one role, it might have to have either the same > opstrategy or different ones in different roles, depending on how the AM > has assigned strategy numbers. The method with an extra index column > side-steps that nicely since there are two unrelated pg_amop entries. > If there's only one entry then you lose if you need different > strategies. Robert's use-the-high-bits method works too, since there > would still be two separate entries, but some other possible > representations are eliminated by that worry. OK, here's another idea. Let's just add a new column to pg_amop called amoporderstrategy. If an operator can only be used for one purpose or the other, we'll set the other value to -1. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
