Re: IN, BETWEEN, spec compliance, and odd operator names

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: IN, BETWEEN, spec compliance, and odd operator names
Date: 2008-08-25 10:14:28
Message-ID: 200808251214.30898.dfontaine@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2008-08-25 11:14:02 Re: can't stop autovacuum by HUP'ing the server
Previous Message Gregory Stark 2008-08-25 09:23:20 Re: IN, BETWEEN, spec compliance, and odd operator names