pg.ddx.io pgsql-performance@postgresql.org mailing list archivehelp / color / mirror / Atom feed
From: Qingqing Zhou <zhouqq@cs.toronto.edu>
To: pgsql-performance@postgresql.org
Subject: Re: performance of implicit join vs. explicit conditions on inet queries?
Date: Tue, 1 Nov 2005 20:19:37 -0500
Message-ID: <dk946n$2m3p$1@news.hub.org> (raw)
References: <20051024035809.GA18261@edmonds.ath.cx>
<dk4p9d$30q4$1@news.hub.org>
<29864.1130768650@sss.pgh.pa.us>
"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. 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.
>
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)');
If there is a GiST/Rtree index associated with all_rectangles.r, how do
optimizer estimate the cost to decide that we should use this index or
not(then by a seqscan)?
(2) Does your above explaination mean that we can't use GiST for a spatial
join operation?
Regards,
Qingqing
view thread (5+ messages) latest in thread
Message-ID: <dk946n$2m3p$1@news.hub.org> Permalink: ../dk946n$2m3p$1@news.hub.org/ Also on: postgresql.org/message-id/dk946n$2m3p$1@news.hub.org ·
reply
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: zhouqq@cs.toronto.edu Subject: Re: performance of implicit join vs. explicit conditions on inet queries? In-Reply-To: <dk946n$2m3p$1@news.hub.org> * 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