On Tue, 27 Jul 2004, Stan Bielski wrote:

> I having a great deal of difficulty getting postgres to do a hash join.
> Even if I disable nestloop and mergejoin in postgres.conf, the optimizer
> still refuses to select hash join. This behavior is killing my
> performance.
> Postgres version is 7.3.2 and relevant tables are vacuum analyzed.
> Here's an overview of what I'm doing:
> I have one table of network logs ordered by time values. The other table
> is a set of hosts (approximately 60) that are infected by a worm. I want
> to do this query on the dataset:
> standb=# explain SELECT count (allflow_tv_sobig.tv_s) FROM
> allflow_tv_sobig, blaster_set WHERE allflow_tv_sobig.src =
> blaster_set.label AND allflow_tv_sobig.tv_s >= 1060101118::bigint and
> allflow_tv_sobig.tv_s < 1060187518::bigint;

Can you send explain analyze results for the normal case and the nested
loop case?  It's generally more useful than plain explain.

I'd also wonder if blaster_set.label is unique such that you might be able
to write the condition as an exists clause and if that's better.  If you
were running 7.4, I'd suggest IN, but that'll certainly be painful in 7.3.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to