Le lundi 25 août 2008, Gregory Stark a écrit : > I'm not sure it's made explicit anywhere in the documentation but those > properties *are* what btree operator classes define. You would end up > duplicating the same structures (like, LT is meaningless unless you > associate it with the corresponding EQUALITY, LE, GT, and GE operators).
But, IIRC, only in the context of index searches, not at the planner level. ISTM the planner can't currently make strong assumptions on operators in order to simplify or analyze some parts of queries... > >> assumptions about the real operator name is required. And then the > >> optimiser can fill in the actual operator by which time it should be > >> clear what it is. > > > > How would the planner get the estimated costs associated to any operator > > choice in this case? > > We don't need to evaluate costs until well after this point. Oh, perfect then. I guess it simply shows I need to read up on PG architecture wrt to how planner/optimiser talk to each other. Regards, -- dim
signature.asc
Description: This is a digitally signed message part.
