Re: [PERFORM] Very slow inner join query Unacceptable latency.

From: Jaime Casanova <jaime(at)2ndquadrant(dot)com>
To: Freddie Burgess <fburgess(at)radiantblue(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, psql performance list <pgsql-performance(at)postgresql(dot)org>, Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: [PERFORM] Very slow inner join query Unacceptable latency.
Date: 2013-05-23 23:34:33
Message-ID: CAJKUy5jN1wt9f0WG3eedrR26BbbSKg3UGRX-am7DYDDfWT8=nQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On Thu, May 23, 2013 at 12:21 PM, <fburgess(at)radiantblue(dot)com> wrote:
>
> But what negative impact is disabling hash joins?
>

doing it just for a single query, could be a tool for solving
particular problems.
setting it in postgresql.conf, therefore affecting all queries, is
like using a hammer to change tv channel... it will cause more
problems than the one it solves.

what you can do is:

1) execute:

SET enable_hashjoin TO OFF;
SELECT here
RESET enable_hashjoin TO ON;

2) in a function:

CREATE FUNCTION do_something() RETURNS bigint AS
$$
SELECT here
$$ LANGUAGE sql SET enable_hashjoin TO OFF STABLE;

--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566 Cell: +593 987171157

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sergey Konoplev 2013-05-23 23:49:57 Re: Find all the the SELECT statements that occured
Previous Message Nathan Clayton 2013-05-23 22:52:21 Re: Success stories of PostgreSQL implementations in different companies

Browse pgsql-performance by date

  From Date Subject
Next Message Jonathan Morra 2013-05-24 00:21:00 Re: Performance of complicated query
Previous Message james 2013-05-23 23:22:03 Re: Performance of complicated query