Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group