mirror of
https://github.com/postgres/postgres.git
synced 2026-02-27 11:50:33 -05:00
e1fad50a5d
hashjoinable clause, not one path for a randomly-chosen element of each set of clauses with the same join operator. That is, if you wrote SELECT ... WHERE t1.f1 = t2.f2 and t1.f3 = t2.f4, and both '=' ops were the same opcode (say, all four fields are int4), then the system would either consider hashing on f1=f2 or on f3=f4, but it would *not* consider both possibilities. Boo hiss. Also, revise estimation of hashjoin costs to include a penalty when the inner join var has a high disbursion --- ie, the most common value is pretty common. This tends to lead to badly skewed hash bucket occupancy and way more comparisons than you'd expect on average. I imagine that the cost calculation still needs tweaking, but at least it generates a more reasonable plan than before on George Young's example. |
||
|---|---|---|
| .. | ||
| access | ||
| bootstrap | ||
| catalog | ||
| commands | ||
| executor | ||
| lib | ||
| libpq | ||
| mb | ||
| nodes | ||
| optimizer | ||
| parser | ||
| port | ||
| regex | ||
| rewrite | ||
| storage | ||
| tcop | ||
| utils | ||
| c.h | ||
| config.h.in | ||
| miscadmin.h | ||
| postgres.h | ||
| postgres_ext.h | ||
| rusagestub.h | ||
| strdup.h | ||
| version.h.in | ||