From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rod Taylor <rbt(at)zort(dot)ca> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Between Node |
Date: | 2002-07-18 20:40:18 |
Message-ID: | 8661.1027024818@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Rod Taylor <rbt(at)zort(dot)ca> writes:
>> In that case, this code is worse than before as far as developing plans
>> goes. The selectivity estimator needs to be taught about what BETWEEN
>> means. Currently it recognizes (x > foo AND x < bar) as a range query
>> --- a BETWEEN node is obviously much easier to recognize, but you still
>> have to add code to do it.
> I simply multiple the results of the left, right and common expression
> after sending them through clause_selectivity() ?
Huh? I don't see any "common expression" here. You've got a left
comparison and a right comparison.
Actually, at least for the case of the standard asymmetric BETWEEN
clause, you really really want to be able to generate a bounded
indexscan plan (indexscan with x > foo AND x < bar as indexquals).
That used to happen for free, and now will not happen at all, because
BETWEEN is not in the set of operators recognized as indexscannable
operators. Not sure what the most appropriate fix is --- there are a
number of places that we could try to fix it at, with varying
implications as to the amount of code changed and the generality of
the cases handled.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2002-07-18 22:00:21 | small psql patch - show Schema name for \dt \dv \dS |
Previous Message | Bruce Momjian | 2002-07-18 20:36:56 | Re: Fix for regression caused by heap tuple header changes |