From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Add BETWEEN SYMMETRIC. |
Date: | 2005-06-15 02:51:51 |
Message-ID: | 27319.1118803911@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Christopher Kings-Lynne wrote:
>> With this Bruce, is there any reason this was accepted now, and not
>> several years ago when I first submitted it? :D
> Uh, I wasn't around then. (No, that isn't going to work.) Uh, no idea.
> I think there is a sense now that doing BETWEEN in gram.y isn't so bad
> because the optimizer can deal with the AND conditation better than
> perhaps it could in the past, but that is total guess.
No, that's exactly it: the original patch was rejected because it made
BETWEEN unoptimizable, IIRC. The change from then to now likely has
more to do with improvements in the optimizer than with the content of
the BETWEEN ASYMMETRIC patch itself.
We are still not totally done on this issue --- as Peter pointed out,
it'd be a lot nicer to represent "a BETWEEN b AND c" as a special
expression node that evaluates "a" only once. BETWEEN ASYMMETRIC is
worse because it may evaluate b and c multiple times too. The missing
part is to teach the optimizer to plan such a thing correctly ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-06-15 05:28:19 | Re: pgsql: Add pg_postmaster_start_time() function. |
Previous Message | Bruce Momjian | 2005-06-15 01:37:50 | Re: [COMMITTERS] pgsql: Fix NUMERIC modulus to properly truncate |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-06-15 03:00:49 | Re: Autovacuum in the backend |
Previous Message | Andrew Dunstan | 2005-06-15 02:34:17 | Re: LGPL |