From: Joe <dev@freedomcircle.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: George Pavlov <gpavlov@mynewplace.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: huge disparities in =/IN/BETWEEN performance
Date: Thu, 08 Feb 2007 23:12:14 -0500
Message-ID: <1170994335.697.55.camel@pampa> (raw)
In-Reply-To: <14273.1170993005@sss.pgh.pa.us>
References: <8C5B026B51B6854CBE88121DBF097A86815F42@ehost010-33.exch010.intermedia.net>
<7377.1170986068@sss.pgh.pa.us>
<8C5B026B51B6854CBE88121DBF097A86815F81@ehost010-33.exch010.intermedia.net>
<20070209021414.GU24069@alvh.no-ip.org>
<14273.1170993005@sss.pgh.pa.us>
Hi Tom,
On Thu, 2007-02-08 at 22:50 -0500, Tom Lane wrote:
> There's a datatype abstraction issue involved: what does it take to
> prove that "x >= 10 AND x <= 10" is equivalent to "x = 10"? This
> requires a nontrivial amount of knowledge about the operators involved.
> We could probably do it for operators appearing in a btree operator
> class, but as Alvaro says, it'd be cycles wasted for non-dumb queries.
Are you saying the planner is datatype-agnostic and can't tell that x
is, say, as in the example above, an INTEGER and therefore cannot
transform one expression into another? What about "x = 10 AND x < 5"?
Can't it reduce that to FALSE?
Joe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: dev@freedomcircle.net, tgl@sss.pgh.pa.us, alvherre@commandprompt.com, gpavlov@mynewplace.com
Subject: Re: huge disparities in =/IN/BETWEEN performance
In-Reply-To: <1170994335.697.55.camel@pampa>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox