From: Tom Lane <tgl@sss.pgh.pa.us>
To: Qingqing Zhou <zhouqq@cs.toronto.edu>
Cc: pgsql-performance@postgresql.org
Subject: Re: performance of implicit join vs. explicit conditions on inet queries?
Date: Tue, 01 Nov 2005 23:20:52 -0500
Message-ID: <1207.1130905252@sss.pgh.pa.us> (raw)
In-Reply-To: <dk946n$2m3p$1@news.hub.org>
References: <20051024035809.GA18261@edmonds.ath.cx>
<dk4p9d$30q4$1@news.hub.org>
<29864.1130768650@sss.pgh.pa.us>
<dk946n$2m3p$1@news.hub.org>
"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
> "Tom Lane" <tgl@sss.pgh.pa.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
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-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, zhouqq@cs.toronto.edu
Subject: Re: performance of implicit join vs. explicit conditions on inet queries?
In-Reply-To: <1207.1130905252@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