Re: Operator COMMUTATOR - how does postgresql use this information

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Obe, Regina" <robe(dot)dnd(at)cityofboston(dot)gov>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Operator COMMUTATOR - how does postgresql use this information
Date: 2008-04-11 16:06:15
Message-ID: 12804.1207929975@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Obe, Regina" <robe(dot)dnd(at)cityofboston(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Andrew Sullivan 2008-04-11 16:41:30 Re: PostgreSQL Processes on a linux box
Previous Message Glyn Astill 2008-04-11 15:35:50 Re: createdb: database creation failed: ERROR: encoding LATIN1 does not match server's locale en_GB.UTF-8