Tom Lane wrote:
Gavin Love writes:
I seem to be unable to get postgres to use a gist index we have on a
circle data type.
SELECT id FROM tradesmen_profiles WHERE tradesmen_profiles.work_area
@> point(0.0548691728419,51.5404384172);
So far as I can see, the member operators of gist circle_
Gavin Love writes:
> I seem to be unable to get postgres to use a gist index we have on a
> circle data type.
> SELECT id FROM tradesmen_profiles WHERE tradesmen_profiles.work_area
> @> point(0.0548691728419,51.5404384172);
So far as I can see, the member operators of gist circle_ops are
g
On Mon, 24 Aug 2009, Gavin Love wrote:
I seem to be unable to get postgres to use a gist index we have on a circle
data type.
QUERY PLAN
---
Seq Scan on tradesmen_profiles (cos
Hey,
I seem to be unable to get postgres to use a gist index we have on a
circle data type.
Table "public.tradesmen_profiles"
Column |Type | Modifiers
---+-+---
id
Kevin Kempter wrote:
> I have a simple query against two very large tables ( > 800million
> rows in theurl_hits_category_jt table and 9.2 million in the
> url_hits_klk1 table )
> I get a very high overall query cost:
> Hash Join (cost=296959.90..126526916.55 rows=441764338 width=8)
Wel
=?ISO-8859-1?Q?G=E1bor_Farkas?= writes:
> i have a query that uses a Hash-Join, but it would be faster with Nested-Loop,
> and i don't know how to persuade postgresql to do it.
Fix the way-off-base rowcount estimates ...
> postgresql-8.2 + tsearch2
... which is just about impossible in 8.2, bec
Greg Stark wrote:
> Creating new catalog entries for [temp tables] gives up -- what I
> think is the whole point of their design -- their lack of DDL
> overhead.
As long as we're brainstorming... Would it make any sense for temp
tables to be created as in-memory tuplestores up to the point th
