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