Re: IN, BETWEEN, spec compliance, and odd operator names - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: IN, BETWEEN, spec compliance, and odd operator names
Date
Msg-id 200808251214.30898.dfontaine@hi-media.com
Whole thread Raw
In response to Re: IN, BETWEEN, spec compliance, and odd operator names  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: IN, BETWEEN, spec compliance, and odd operator names  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: IN, BETWEEN, spec compliance, and odd operator names
Next
From: Dave Cramer
Date:
Subject: Re: can't stop autovacuum by HUP'ing the server