Re: Quadratic planning time for ordered paths over partitioned tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Kuzmenkov <akuzmenkov(at)timescale(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Quadratic planning time for ordered paths over partitioned tables
Date: 2025-01-22 17:15:23
Message-ID: 3937316.1737566123@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alexander Kuzmenkov <akuzmenkov(at)timescale(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-01-22 17:36:01 Re: Converting pqsignal to void return
Previous Message Alvaro Herrera 2025-01-22 17:05:13 Re: Quadratic planning time for ordered paths over partitioned tables