From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: nested loop semijoin estimates |
Date: | 2015-05-30 21:11:42 |
Message-ID: | 556A278E.1010703@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/30/15 21:50, Tom Lane wrote:
> So what this seems to mean is that for SEMI/ANTI join cases, we have
> to postpone all of the inner scan cost determination to
> final_cost_nestloop, so that we can do this differently depending on
> whether has_indexed_join_quals() is true. That's a little bit
> annoying because it will mean we take the shortcut exit less often;
> but since SEMI/ANTI joins aren't that common, it's probably not
> going to be a big planning time hit.
Yay! So I wasn't entirely wrong on this. Do you plan to make this
change, or will you leave that on me?
>
> Not sure yet about your other point about the indexscan getting
> rejected too soon. That doesn't seem to be happening for me, at least
> not in HEAD.
FWIW I can reproduce that reliably on current HEAD, with the test case I
sent yesterday. I'm using default config (as produced by initdb).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-05-30 21:16:27 | Re: nested loop semijoin estimates |
Previous Message | Andres Freund | 2015-05-30 21:02:32 | Re: [CORE] postpone next week's release |