Boszormenyi Zoltan <z...@cybertec.at> writes: > Tom Lane írta: >> That seems like a ridiculously large number of ECs. What is the >> test query again?
> The test case is here: > http://archives.postgresql.org/message-id/4cbd9ddc.4040...@cybertec.at After poking through that a bit, I think that the real issue is in this division of labor: index_pathkeys = build_index_pathkeys(root, index, ForwardScanDirection); useful_pathkeys = truncate_useless_pathkeys(root, rel, index_pathkeys); If you trace what is happening here, the index pathkeys that actually survive the "usefulness" test all refer to exactly ONE equivalence class, namely the one arising from the query's "order by timestamp2" clause. All the other pathkeys that get created are immediately discarded as being irrelevant to the query. The reason that we end up with so many equivalence classes is that there is nothing causing the variables of the different child tables to be recognized as all sort-equivalent. Maybe that's a bug in itself, but I would argue that the right way to make this faster is to refactor things so that we don't generate useless equivalence classes in the first place, or at least don't keep them around in the planner's lists once we realize they're useless. I like Heikki's hack to cut down on searching in make_canonical_pathkey, but I think that complicating the data structure searching beyond that is just a band-aid. Reasonably-sized queries shouldn't contain very many equivalence classes: they should only come from equality clauses or sort conditions that appeared in the query text. Therefore, there also shouldn't be all that many distinct pathkeys. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
