mirror of
https://github.com/postgres/postgres.git
synced 2026-02-17 09:42:54 -05:00
15b9d47c8e
classify_index_clause_usage() is O(N^2) in the number of distinct index qual clauses it considers, because of its use of a simple search list to store them. For nearly all queries, that's fine because only a few clauses will be considered. But Alexander Kuzmenkov reported a machine-generated query with 80000 (!) index qual clauses, which caused this code to take forever. Somewhat remarkably, this is the only O(N^2) behavior we now have for such a query, so let's fix it. We can get rid of the O(N^2) runtime for cases like this without much damage to the functionality of choose_bitmap_and() by separating out paths with "too many" qual or pred clauses, and deeming them to always be nonredundant with other paths. Then their clauses needn't go into the search list, so it doesn't get too long, but we don't lose the ability to consider bitmap AND plans altogether. I set the threshold for "too many" to be 100 clauses per path, which should be plenty to ensure no change in planning behavior for normal queries. There are other things we could do to make this go faster, but it's not clear that it's worth any additional effort. 80000 qual clauses require a whole lot of work in many other places, too. The code's been like this for a long time, so back-patch to all supported branches. The troublesome query only works back to 9.5 (in 9.4 it fails with stack overflow in the parser); so I'm not sure that fixing this in 9.4 has any real-world benefit, but perhaps it does. Discussion: https://postgr.es/m/90c5bdfa-d633-dabe-9889-3cf3e1acd443@postgrespro.ru |
||
|---|---|---|
| .. | ||
| backend | ||
| bin | ||
| common | ||
| fe_utils | ||
| include | ||
| interfaces | ||
| makefiles | ||
| pl | ||
| port | ||
| template | ||
| test | ||
| timezone | ||
| tools | ||
| tutorial | ||
| .gitignore | ||
| DEVELOPERS | ||
| Makefile | ||
| Makefile.global.in | ||
| Makefile.shlib | ||
| nls-global.mk | ||