On Wed, Jun 28, 2000 at 03:00:04AM -0400, Tom Lane wrote:
> Hash joins don't have anything to do with hash indexes.
> A hash join is a join that makes use of a temporary hashtable
> built on-the-fly *in memory* for that join.
Oh, I see.
> The planner could choose to use an indexscan on a hash index
> as an input for the join, but it'd only be likely to do so
> if there is a restriction clause matching the index. In your
> example you have only a join WHERE clause.
Well, in my original query, there was, but the plan's the same.
Probably the clause wasn't restrictive enough (" and region < n").
Original cost est:
Hash Join (cost=8.85..16.76 rows=75 width=18) -> Seq Scan on city (cost=0.00..1.75 rows=75 width=16) -> Hash
(cost=5.53..5.53rows=253 width=2) -> Seq Scan on country (cost=0.00..5.53 rows=253 width=2)
I guess the problem is that country-city is a one-to-many relation,
BUT I've more countries than cities (note the # of rows above), thus
throwing the planner off...
OTOH, what's bugging me is that Postgresql could have used
pre-generated hash index rather rebuilding it on the fly again.
> Plain btree indexes on city.country_id and country.country_id
> might work better --- at least they'd offer the option of
> a merge join without doing explicit sort.
I tried, and it did worse.
Hmmm... I think I'm better off creating a temporary table
to store the results, since the table is seldom updated
but that query is run often. Rules to update that temp. table, too,
of course.
(cost is now 1.75, if anyone cares)
