Re: Anti join confusion
От | Robert Haas |
---|---|
Тема | Re: Anti join confusion |
Дата | |
Msg-id | CA+TgmoYMLXFJuVjrT-6pkQNFFA3AgN_EwZBpF5Vg21HXqqL-Kg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Anti join confusion (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Anti join confusion
|
Список | pgsql-hackers |
On Wed, Feb 26, 2025 at 4:58 PM Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: