Re: Optimizer refuses to hash join

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Stan Bielski <bielski(at)ece(dot)cmu(dot)edu>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Optimizer refuses to hash join
Date: 2004-07-29 16:08:55
Message-ID: 20040729090450.D97947@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2004-07-29 16:48:51 Re: best way to fetch next/prev record based on index
Previous Message pathat 2004-07-29 15:54:49 Extremely slow query...