Re: [BUGS] New hashed IN code ignores distinctiveness of subquery
| От | Tom Lane |
|---|---|
| Тема | Re: [BUGS] New hashed IN code ignores distinctiveness of subquery |
| Дата | |
| Msg-id | 8193.1043702992@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [BUGS] New hashed IN code ignores distinctiveness of subquery (Bradley Baetz <bbaetz@acm.org>) |
| Список | pgsql-hackers |
Bradley Baetz <bbaetz@acm.org> writes:
> Hmm. OK, I poked through the code a bit more, and I think I now realise
> why we were talking across each other. I've attached a 'patch' which
> gets the mergejoin counts down to something reasonable.
I've just committed a significant set of changes in the join cost
estimation routines. On looking closer, they hadn't been upgraded for
any of the recent changes --- they were still assuming that merge and
hash join clauses could only be simple var = var, for instance. I did
something about the mergejoin rescan issue, as well as modeling JOIN
short-circuiting. All of the estimates are a bit crude, but certainly
better than no model at all.
I think this covers your concerns, though I'm still worried about
whether it's okay to use the existing selectivity routines to compute
selectivities in the JOIN_IN/JOIN_UNIQUE case.
regards, tom lane
В списке pgsql-hackers по дате отправления: