| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> | 
| Cc: | Daniel Farina <daniel(at)heroku(dot)com>, Will Leinweber <will(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: query planner does not canonicalize infix operators | 
| Date: | 2012-04-15 15:21:22 | 
| Message-ID: | 8619.1334503282@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Looks like we're missing out some operator properties, like the neutral
> element and if the operator is transitive, commutative or associative. I
> think I remember us talking about how knowing about operators being
> associative would also help optimize a class of join problems.
We do understand, and use, transitivity for btree equality operators
(cf mergejoin planning, EquivalenceClasses, etc).  I have limited
enthusiasm for introducing a more general concept, because it seems like
doing anything with it would add a great deal more planning effort for
(typically) little reward.  I can imagine cases where, say, deducing
"a < c" from "a < b and b < c" would be helpful ... but they don't come
up in common queries.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-04-15 15:25:12 | Re: Clobbered parameter names via DECLARE in PL/PgSQL | 
| Previous Message | Heikki Linnakangas | 2012-04-15 14:32:25 | Re: documentation bug - missing info about unpackaged control files for extension |