> 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
In response to
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2010-10-29 06:23:43|
|Subject: Re: sorted writes for checkpoints|
|Previous:||From: Pavel Golub||Date: 2010-10-29 05:47:46|
|Subject: Re: add label to enum syntax|