> -Original Message-
> From: negora [mailto:neg...@negora.com]
> Sent: Tuesday, February 23, 2010 4:33 PM
> To: Scott Carey
> Cc: Alvaro Herrera; pgsql-performance@postgresql.org
> Subject: Re: Internal operations when the planner makes a hash join.
>
> Thank you for explaining me the
>negora wrote:
> I even might return the entire result to my external Java
> application
You are probably going to want to configure it to use a cursor, at
least if the result set is large (i.e., too big to cache the entire
result set in memory before you read the first row). Read this over
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 entir
negora 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
Thank you for explaining me the internal behaviour of the PostgreSQL
engine. I'll try to look for more information about that hash tables. It
sounds really really interesting. Your information was very useful.
The origin of my doubt resides in the fact that I need to do a joint
between 3 HUGE
On Feb 23, 2010, at 8:53 AM, Alvaro Herrera wrote:
> negora wrote:
>
>> According to how I understood the process, the engine would get the
>> name from the student with ID 1 and would look for the name of the
>> father with ID 1 in the hashed table. It'd do exactly the same with the
>> student
negora wrote:
> According to how I understood the process, the engine would get the
> name from the student with ID 1 and would look for the name of the
> father with ID 1 in the hashed table. It'd do exactly the same with the
> student #2 and father #2. But my big doubt is about the 3rd one
> (An
First of all, thank you for your fast answer,
Kevin :) .
However I still wonder if on the search into the hashed
table (stored in the RAM, as you're pointing out), it checks for
fathers as
many times as students are selected, or if the engine uses some kind of
intelligent heuristic to avoid se
negora wrote:
> I've a doubt about how the PostgreSQL planner makes a hash join.
> Let's suppose that I've 2 tables, one of students and the other
> one of parents in a many-to-one relation. I want to do something
> like this:
>
> SELECT s.complete_name, f.complete_name
> FROM
Hello:
I'm an ignorant in what refers to performance analysis of PostgreSQL.
I've a doubt about how the PostgreSQL planner makes a hash join. I've
tried to "dig" into the archive of this mailing list but I haven't found
what I'm looking for. So I'm explaining my doubt with an example to see
if an
Hello:
I'm an ignorant in what refers to performance analysis of PostgreSQL.
I've a doubt about how the PostgreSQL planner makes a hash join. I've
tried to "dig" into the archive of this mailing list but I haven't found
what I'm looking for. So I'm explaining my doubt with an example to see
i
11 matches
Mail list logo
