| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Subject: | Re: Fixing Grittner's planner issues |
| Date: | 2009-02-19 18:20:49 |
| Message-ID: | 17145.1235067649@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
[ back to planner stuff after a hiatus ]
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Right, so maybe I wasn't as clear as I could have been in asking the
> question. I do understand how it can be a win to unique B and use it
> as the OUTER relation (jointype JOIN_UNIQUE_OUTER). What I don't
> understand is how it can ever be a win to unique B and use it as the
> INNER relation (jointype JOIN_UNIQUE_INNER).
Hmm, well, maybe B is *really* nonunique and unique'ifying it makes it
small enough to fit in a single-batch hash table?
Also, seriously nonunique RHS data is pretty awful for mergejoining
(too much rescanning) so I could imagine wanting to do it for a
mergejoin too.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2009-02-19 18:24:52 | Re: vacuumdb --freeze |
| Previous Message | Tom Lane | 2009-02-19 17:49:51 | Re: vacuumdb --freeze |