Re: plan time of MASSIVE partitioning ...

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Boszormenyi Zoltan <zb@cybertec.at>

Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Alvaro Herrera <alvherre@commandprompt.com>, Stephen Frost <sfrost@snowman.net>, Hans-Jürgen Schönig <postgres@cybertec.at>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers Hackers <pgsql-hackers@postgresql.org>, Josh Berkus <josh@agliodbs.com>

Date: 2010-10-29T06:08:34Z

Lists: pgsql-hackers

Attachments

avoid-useless-eclasses.patch (text/x-patch) patch

I wrote:
> 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.

After a bit of hacking, I propose the attached patch.

> 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.

With the given test case and this patch, we end up with exactly two
canonical pathkeys referencing a single EquivalenceClass.  So as far
as I can tell there's not a lot of point in refining the pathkey
searching.  Now, the EquivalenceClass has got 483 members, which
means that there's still some O(N^2) behavior in
get_eclass_for_sort_expr.  There might be some use in refining the
search for a matching eclass member.  It's not sticking out in
profiling like it did before though.

			regards, tom lane