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
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 |
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 |