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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
