From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Kuzmenkov <akuzmenkov@timescale.com>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, pgsql-hackers@postgresql.org
Subject: Re: Quadratic planning time for ordered paths over partitioned tables
In-reply-to: <CALzhyqzvYqaZ9iaOQOpV2Ga=h4549UfaU6BFDNOpTU+scgnRUA@mail.gmail.com>
References: <CALzhyqzmZ6b9Sbp4jCORJV48t4kz2a1EqR3z4DUxX4RfRYR2xA@mail.gmail.com> <202501221636.mynlx5r3tba4@alvherre.pgsql> <CALzhyqzvYqaZ9iaOQOpV2Ga=h4549UfaU6BFDNOpTU+scgnRUA@mail.gmail.com>
Comments: In-reply-to Alexander Kuzmenkov <akuzmenkov@timescale.com>
	message dated "Wed, 22 Jan 2025 17:50:37 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3937315.1737566123.1@sss.pgh.pa.us>
Date: Wed, 22 Jan 2025 12:15:23 -0500
Message-ID: <3937316.1737566123@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3937316.1737566123%40sss.pgh.pa.us>
Precedence: bulk

Alexander Kuzmenkov <akuzmenkov@timescale.com> writes:
> Yeah, I'm referencing this one in my email, but it's a series of
> patches that does a major refactoring changing thousands of lines. I'm
> not sure when or if it's going to land, do you think applying a quick
> fix first would make sense? It makes trivial changes in one function.

That "quick fix" seems extremely horrid: since there's only one static
cache variable for all ECs, it's going to help only one very specific
call pattern, which could easily get broken by unrelated changes.
Also, maybe my performance instincts are rooted in old hardware, but
I don't trust integer division with a variable divisor to be cheap.
So ISTM this could as easily make things worse as better.  If you
offered something that was less obviously a kluge, maybe we could
use it.

Really I'd think the right place to be fixing this is at a higher
level.  Where are the repetitive find_ec_member_matching_expr calls
coming from?

			regards, tom lane