Re: Block nested loop join

From: "Bramandia Ramadhana" <bramandia(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Block nested loop join
Date: 2008-10-13 09:14:18
Message-ID: 700260640810130214t6b99761et34a471dfc90d13a6@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear All,

I took a look at the source code for hash join this morning and I realized
that the block nested loop join is somewhat similar to that.

Thanks for the discussions.

Bramandia R.

On Fri, Oct 10, 2008 at 8:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> > So the use case of a real block nested loop would be doing a cartesian
> join of
> > two large tables where neither fits in RAM. That does seem like it might
> be
> > kind of narrow given how large the output would be.
>
> Yeah. If you have a hashable join condition then our existing batched
> hash join code should be roughly equivalent to this method. So the use
> case is joining a couple of large tables with an un-hashable,
> un-indexable join condition (or none at all, ie cross product) and that
> just isn't something we hear people wanting to do a lot. I can't really
> see why we'd bother maintaining extra code for block nested loop.
>
> regards, tom lane
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2008-10-13 09:15:17 Re: [PATCH] Extending pg_class info + more flexible TOAST chunk size
Previous Message ITAGAKI Takahiro 2008-10-13 09:00:44 Convert check constraints into One-Time_Filter on prepared statements