Re: Internal operations when the planner makes a hash join.

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "negora" <negora(at)negora(dot)com>, "Scott Carey" <scott(at)richrelevance(dot)com>
Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Internal operations when the planner makes a hash join.
Date: 2010-02-23 21:45:21
Message-ID: 4B83F811020000250002F579@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

negora <negora(at)negora(dot)com> wrote:

> The origin of my doubt resides in the fact that I need to do a
> joint between 3 HUGE tables (millions of registries) and do
> certain operations with the retrieved information. I was deciding
> whether to use one SELECT with 3 JOINs, as I've been doing since
> the beginning, or build a PL/PgSQL function based on 3 nested "FOR
> ... IN SELECT ... LOOP" structures which tried to minimize the
> subsequent table searches storing intermediate useful data in
> arrays

It's almost always faster (and less error prone) to write one SELECT
statement declaring what you want than to try to do better by
navigating individual rows procedurally. I would *strongly*
recommend you write it with the JOINs and then post here if you have
any concerns about the performance. In general, try to *declare*
what you want, and let the PostgreSQL planner sort out the best way
to navigate the tables to produce what you want. If you hit some
particular weakness in the planner, you many need to coerce it, but
certainly you should not *start* with that.

-Kevin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Ben Chobot 2010-02-23 22:14:02 Re: moving pg_xlog -- yeah, it's worth it!
Previous Message negora 2010-02-23 21:33:24 Re: Internal operations when the planner makes a hash join.