Request a Demo
Home   >   mailing lists

Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop() - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Date
Msg-id CA+TgmobPBCvTHnBVn+a-=MS7pO_PUvtiLJkYo=BOrUjOxTss8g@mail.gmail.com
Whole thread Raw
In response to Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
List pgsql-hackers
Tree view 
On Tue, Sep 5, 2023 at 8:07 AM Richard Guo <guofenglinux@gmail.com> wrote:
> Yeah, this seems an omission in commit 45be99f8.

It's been a while, but I think I omitted this deliberately because I
didn't really understand the value of it and wanted to keep the
planning cost down.

The example query provided here seems rather artificial. Surely few
people write a join clause that references neither of the tables being
joined. Is there a more realistic case where this makes a big
difference?

--
Robert Haas
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Eliminate redundant tuple visibility check in vacuum
Next
From: Robert Haas
Date:
Subject: Re: Eliminate redundant tuple visibility check in vacuum