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

[negora]

Hello Kevin. I'm going to take and apply your advices, certainly. No more "crazy" PL/PgSQLs then. I was worried because of the possibility that repetition of fields caused some kind of memory saturation. But I guess that PostgreSQL takes care of that fact properly. I even might return the entire result to my external Java application (I was using a similar approach on it too). I just hope that the speed of that single SQL compensates the transfer of such a big mass of data between PostgreSQL and Java in terms of delay. Thanks ;) . Kevin Grittner wrote: negora <neg...@negora.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