Re: surprisingly expensive join planning query

On Sun, Dec 01, 2019 at 02:17:15PM -0500, Tom Lane wrote:
>Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>> On Sun, Dec 01, 2019 at 01:27:04PM -0500, Tom Lane wrote:
>>> Alternatively, it'd be possible to get rid of the separate List
>>> altogether, and just add the rinfo's to "mergeclauses" immediately.
>>> The functionality of the separate list could be replaced by a
>>> bool variable remembering whether we found any matches in this
>>> pass through the loop. I think the code would be a little less
>>> clear that way, but this report makes it clear that it's a
>>> performance bottleneck, so maybe we should just change it.
>
>> Yes, that might be an option. And it works even on 9.5 for me (per the
>> attached patch). I don't think it's much less clear compared to just
>> doing an explicit free at the end.
>
>LGTM.
>

Thanks. Do you think this is backpatch-worthy? I'm leaning to yes, but
maybe tweaking this just in master is fine. The query is somewhat
artificial and there are probably ways to rewrite it.

The thing that annoys me a bit is that this fix is only partial. It gets
rid of maybe 80% of the allocations, but there's plenty of unnecessary
stuff left allocated ...

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services