On Fri, Jan 24, 2025 at 2:37 PM Alvaro Herrera wrote:
> I ran Kuzmenkov's test case with Watari-san's patch. Planning time goes
> from 2700ms to 600ms or so.
Thank you, good to know that it helps this case as well.
On 2025-Jan-24, Aleksander Alekseev wrote:
> Did you consider checking if the referenced patchset addresses the
> issue you described?
I ran Kuzmenkov's test case with Watari-san's patch. Planning time goes
from 2700ms to 600ms or so.
--
Álvaro HerreraBreisgau, Deutschland — https://
Hi,
> > I think this is closely related to the work Yuya Watari has been doing
> > at
> > https://postgr.es/m/caj2pmkzzhrhgq5uv0y+stkqx7xvgzenmhl98ubkm-oarvk9...@mail.gmail.com
> > Perhaps you could contribute by reviewing that patch series.
>
> Yeah, I'm referencing this one in my email, but it's
Alexander Kuzmenkov 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
On Wed, Jan 22, 2025 at 6:15 PM Tom Lane wrote:
> 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?
I'm not aware of the repeated calls for the same child, and I mostly
see it called once for ever
On 2025-Jan-22, Alexander Kuzmenkov wrote:
> On Wed, Jan 22, 2025 at 5:36 PM Alvaro Herrera
> wrote:
> > I think this is closely related to the work Yuya Watari has been doing
> > at
> > https://postgr.es/m/caj2pmkzzhrhgq5uv0y+stkqx7xvgzenmhl98ubkm-oarvk9...@mail.gmail.com
> > Perhaps you could
On Wed, Jan 22, 2025 at 5:36 PM Alvaro Herrera wrote:
> I think this is closely related to the work Yuya Watari has been doing
> at
> https://postgr.es/m/caj2pmkzzhrhgq5uv0y+stkqx7xvgzenmhl98ubkm-oarvk9...@mail.gmail.com
> Perhaps you could contribute by reviewing that patch series.
Yeah, I'm ref
Hello,
On 2025-Jan-22, Alexander Kuzmenkov wrote:
> Hi hackers,
>
> There's currently an unfortunate CPU sink in the planning for
> partitioned tables. It happens both for the declarative partitioning,
> and for the partitioning through inheritance like we use in
> TimescaleDB.
>
> The gist of
Hi hackers,
There's currently an unfortunate CPU sink in the planning for
partitioned tables. It happens both for the declarative partitioning,
and for the partitioning through inheritance like we use in
TimescaleDB.
The gist of it is that there's a linear search of the EM corresponding
to the gi
