From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: performance of implicit join vs. explicit conditions on inet queries? |
Date: | 2005-11-02 04:20:52 |
Message-ID: | 1207.1130905252@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote
>> No, that's completely irrelevant to his problem. The reason we can't do
>> this is that the transformation from "x << const" to a range check on x
>> is a plan-time transformation; there's no mechanism in place to do it
>> at runtime.
> Not quite understand, sorry ...
> (1) For this query (in an as-is PG syntax, which find out all rectangles lie
> in a given rectangle) :
> SELECT r FROM all_rectangles
> WHERE r << rectangle('(1,9),(9,1)');
No, you're thinking of the wrong << operator. The question was about
the inet network inclusion operator. We have a special case in
indxpath.c to transform "inetcol << inetconstant" into a range check
on the inet variable, much like we can transform a left-anchored LIKE
pattern into a range check on the text variable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | PostgreSQL | 2005-11-02 09:32:45 | Re: 8.1beta3 performance |
Previous Message | Qingqing Zhou | 2005-11-02 01:19:37 | Re: performance of implicit join vs. explicit conditions on inet queries? |