public inbox for [email protected]
help / color / mirror / Atom feedFrom: Lepikhov Andrei <[email protected]>
To: Yuya Watari <[email protected]>
To: Ashutosh Bapat <[email protected]>
Cc: David Rowley <[email protected]>
Cc: Thom Brown <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Zhang Mingli <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: PostgreSQL Developers <[email protected]>
Subject: Re: [PoC] Reducing planning time when tables have many partitions
Date: Fri, 22 Sep 2023 10:48:38 +0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAJ2pMkaNzmvMUm9igQwRH0AAo39gsjnE1VXupPGyLR2T7ENnUQ@mail.gmail.com>
References: <CAJ2pMkZwp545Fj=vyiyy=j=zPAEisb1=72PAU6vwyNc=Nx9vpA@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAExHW5uVZ3E5RT9cXHaxQ_DEK7tasaMN=D6rPHcao5gcXanY5w@mail.gmail.com>
<CAJ2pMkbuww_+QG4oeH7OvbKZt6TXafXJS6enkqnqVwh-mSOKhg@mail.gmail.com>
<CAExHW5uOoBHNjfFwiDWMZseFwaky_XGmki7N7oHGqhUZX4WZnQ@mail.gmail.com>
<CAJ2pMkZrFS8EfvZpkw9CP0iqWk=EaAxzaKWS7dW+FTtqkUOWxA@mail.gmail.com>
<[email protected]>
<CAExHW5sVdtC0aKRvD-gByYvLxxM+jTfOoaSDq_zSPC-3oc0yqw@mail.gmail.com>
<[email protected]>
<CAExHW5s-6WP2pQK_D9q92Ncbyvj+rDncofMJ4JGh0pkrh9FdRA@mail.gmail.com>
<CAJ2pMkaN57du6Yw+oomt44Ru+P2Hdp+vigexeYqUtbwyy=8SGA@mail.gmail.com>
<CAApHDvqp0UrCf9FLGyPWruiuU6BfPPquDxE2Wxw7ZS2S1FNH0A@mail.gmail.com>
<CAJ2pMka06YYV9UYx+NT1zkJO0ah+KHYWJ2vOmV2qGphfU5TjeQ@mail.gmail.com>
<CAJ2pMkZk-Nr=yCKrGfGLu35gK-D179QPyxaqtJMUkO86y1NmSA@mail.gmail.com>
<[email protected]>
<CAJ2pMkaNzmvMUm9igQwRH0AAo39gsjnE1VXupPGyLR2T7ENnUQ@mail.gmail.com>
On Wed, Sep 20, 2023, at 5:04 PM, Yuya Watari wrote:
> On Tue, Sep 19, 2023 at 5:21 PM Andrey Lepikhov
> <[email protected]> wrote:
>> Working on self-join removal in the thread [1] nearby, I stuck into the
>> problem, which made an additional argument to work in this new direction
>> than a couple of previous ones.
>> With indexing positions in the list of equivalence members, we make some
>> optimizations like join elimination more complicated - it may need to
>> remove some clauses and equivalence class members.
>> For changing lists of derives or ec_members, we should go through all
>> the index lists and fix them, which is a non-trivial operation.
>
> Thank you for looking into this and pointing that out. I understand
> that this problem will occur somewhere like your patch [1] quoted
> below because we need to modify RelOptInfo->eclass_child_members in
> addition to ec_members. Is my understanding correct? (Of course, I
> know ec_[no]rel_members, but I doubt we need them.)
It is okay if we talk about the self-join-removal feature specifically because joins are removed before an inheritance expansion.
But ec_source_indexes and ec_derive_indexes point to specific places in eq_sources and eq_derives lists. If I removed an EquivalenceClass or a restriction during an optimisation, I would arrange all indexes, too.
Right now, I use a workaround here and remove the index link without removing the element from the list. But I'm not sure how good this approach can be in perspective.
So, having eq_sources and eq_derives localised in EC could make such optimisations a bit more simple.
--
Regards,
Andrei Lepikhov
view thread (29+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PoC] Reducing planning time when tables have many partitions
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox