Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group