Re: Anti join confusion

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tender Wang <tndrwang(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Anti join confusion
Date: 2025-02-27 01:39:04
Message-ID: CA+TgmoYMLXFJuVjrT-6pkQNFFA3AgN_EwZBpF5Vg21HXqqL-Kg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 26, 2025 at 4:58 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yeah. The key problem blocking doing something about it in the
> planner is that at the time we want to do join tree restructuring,
> we haven't yet collected the per-relation data that would allow
> us to know about NOT NULL constraints, nor run expression
> simplification that would be important for detecting all but the
> most basic cases. Doing either of those things twice seems like
> a nonstarter from a planner-speed viewpoint. It's possible that
> we could rearrange things to collect catalog data sooner.
> (I'm vaguely imagining that we'd collect that stuff by relation
> OID to begin with, and then when we build RelOptInfos later on
> we could link to the per-rel-OID catalog data.) Moving expression
> simplification up seems considerably more fraught, but maybe we could
> handle the cases of common interest without having done that.

Oh, this is very helpful! I didn't realize that there were specific
technical obstacles standing in the way of making this happen; I was
assuming it was just a case of nobody having been interested enough to
write the code. That's good to know.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-02-27 01:55:33 Re: Anti join confusion
Previous Message Michael Paquier 2025-02-27 00:46:49 Re: Spinlock can be released twice in procsignal.c