From: Tom Lane <tgl@sss.pgh.pa.us>
To: 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 22:50:05 -0500
Message-ID: <14273.1170993005@sss.pgh.pa.us> (raw)
In-Reply-To: <20070209021414.GU24069@alvh.no-ip.org>
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>
Alvaro Herrera <alvherre@commandprompt.com> writes:
> I think the principle here is that the system is not gonna waste cycles
> on dumb queries. Supposedly, morphing "foo BETWEEN 10 and 10" into
> "foo=10" is not a trivial transformation, and it'd impose a planning
> cost on all non-dumb BETWEEN queries.
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.
As for the IN case, I think we do simplify "x IN (one-expression)" to
"x = one-expression", but "x IN (sub-select)" is a whole 'nother matter,
especially when you're comparing it to a case where one-expression is
a constant and so the planner can get good statistics about how many
rows are likely to match.
regards, tom lane
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: tgl@sss.pgh.pa.us, alvherre@commandprompt.com, gpavlov@mynewplace.com
Subject: Re: huge disparities in =/IN/BETWEEN performance
In-Reply-To: <14273.1170993005@sss.pgh.pa.us>
* 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