Horton

Re: [PoC] Reducing planning time when tables have many partitions

Andrei Lepikhov <a.lepikhov@postgrespro.ru>

View thread
From: "Lepikhov Andrei" <a.lepikhov@postgrespro.ru>
To: "Yuya Watari" <watari.yuya@gmail.com>, "Ashutosh Bapat" <ashutosh.bapat.oss@gmail.com>
Cc: "David Rowley" <dgrowleyml@gmail.com>, "Thom Brown" <thom@linux.com>, "Alvaro Herrera" <alvherre@alvh.no-ip.org>, "Zhang Mingli" <zmlpostgres@gmail.com>, "Tom Lane" <tgl@sss.pgh.pa.us>, "PostgreSQL Developers" <pgsql-hackers@lists.postgresql.org>
Date: 2023-09-22T03:48:38Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Update wording in optimizer/README for EquivalenceClasses

  2. Speedup child EquivalenceMember lookup in planner

  3. Allow planner to use Merge Append to efficiently implement UNION

  4. Remove trailing zero words from Bitmapsets

  5. Make Vars be outer-join-aware.

  6. Avoid making commutatively-duplicate clauses in EquivalenceClasses.

On Wed, Sep 20, 2023, at 5:04 PM, Yuya Watari wrote:
> On Tue, Sep 19, 2023 at 5:21 PM Andrey Lepikhov
> <a.lepikhov@postgrespro.ru> 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