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
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 |