Re: Operator COMMUTATOR - how does postgresql use this information - Mailing list pgsql-general

From Tom Lane
Subject Re: Operator COMMUTATOR - how does postgresql use this information
Date
Msg-id 12804.1207929975@sss.pgh.pa.us
Whole thread Raw
In response to Operator COMMUTATOR - how does postgresql use this information  ("Obe, Regina" <robe.dnd@cityofboston.gov>)
List pgsql-general
"Obe, Regina" <robe.dnd@cityofboston.gov> writes:
> Does PostgreSQL use the COMMUTATOR property of an operator to determine
> if flip-flopped arguments can be collapsed.

No.  In recent releases we don't even bother to look for simple
duplicate clauses (it's seldom worth the cycles), let alone clauses that
would be duplicates after some transformation or other.

> I used to think it did until someone pointed it doesn't  - For example
> in the below

> SELECT b.*
> FROM boszip b INNER JOIN landparcels l
> ON (b.the_geom && l.the_geom  AND l.the_geom && b.the_geom AND
> l.the_geom && b.the_geom )
> WHERE l.gid = b.gid and b.gid = l.gid
> limit 1

> If I look at the query plan - I see the plan has reduced things down to

> l.gid = b.gid  AND (b.the_geom && l.the_geom  AND l.the_geom &&
> b.the_geom)

8.3 will do that (prior releases will often fail to recognize the
redundancy) but it's an outgrowth of mergejoin equivalence-class
processing.  && isn't a mergejoinable equality operator so nothing much
happens to those clauses.

            regards, tom lane

pgsql-general by date:

Previous
From: Glyn Astill
Date:
Subject: Re: createdb: database creation failed: ERROR: encoding LATIN1 does not match server's locale en_GB.UTF-8
Next
From: Reece Hart
Date:
Subject: tsearch2 and hyphenated terms