X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 2A428DB52D
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Mon, 31 Oct 2005 10:24:14 -0400 (AST)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 05027-04
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Mon, 31 Oct 2005 14:24:10 +0000 (GMT)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by svr1.postgresql.org (Postfix) with ESMTP id 602B2DAB77
	for <pgsql-performance@postgresql.org>;
	Mon, 31 Oct 2005 10:24:12 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j9VEOA4L029865;
	Mon, 31 Oct 2005 09:24:10 -0500 (EST)
To: "Qingqing Zhou" <zhouqq@cs.toronto.edu>
Cc: pgsql-performance@postgresql.org, edmonds42@bellsouth.net
Subject: Re: performance of implicit join vs. explicit conditions on inet
	queries?
In-reply-to: <dk4p9d$30q4$1@news.hub.org> 
References: <20051024035809.GA18261@edmonds.ath.cx>
	<dk4p9d$30q4$1@news.hub.org>
Comments: In-reply-to "Qingqing Zhou" <zhouqq@cs.toronto.edu>
	message dated "Mon, 31 Oct 2005 04:48:41 -0500"
Date: Mon, 31 Oct 2005 09:24:10 -0500
Message-ID: <29864.1130768650@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.144 required=5 tests=[AWL=-0.132,
	MAILTO_TO_SPAM_ADDR=0.276]
X-Spam-Score: 0.144
X-Spam-Level: 
X-Archive-Number: 200510/470
X-Sequence-Number: 15238

"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
> "Robert Edmonds" <edmonds42@bellsouth.net> wrote
>> Instead of specifying explicit address ranges in the query, I'd like
>> to store the ranges in a table:

> Good illustration. I guess we have a problem of the historgram statistical 
> information.

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.  This is not easy to fix, because the mechanism that's doing
it is primarily intended for LIKE/regex index optimization, and in that
case a runtime pattern might well not be optimizable at all.

			regards, tom lane