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
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 |