Re: Patch to support SEMI and ANTI join removal
От | Tom Lane |
---|---|
Тема | Re: Patch to support SEMI and ANTI join removal |
Дата | |
Msg-id | 18703.1410450446@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Patch to support SEMI and ANTI join removal (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Patch to support SEMI and ANTI join removal
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Sep 11, 2014 at 7:14 AM, David Rowley <dgrowleyml@gmail.com> wrote: >> 5. I've added a flag to pg_class called relhasfkey. Currently this gets set >> to true when a foreign key is added, though I've added nothing to set it >> back to false again. I notice that relhasindex gets set back to false during >> vacuum, if vacuum happens to find there to not be any indexes on the rel. I >> didn't put my logic here as I wasn't too sure if scanning pg_constraint >> during a vacuum seemed very correct, so I just left out the "setting it to >> false" logic based on the the fact that I noticed that relhaspkey gets away >> with quite lazy setting back to false logic (only when there's no indexes of >> any kind left on the relation at all). > The alternative to resetting the flag somehow is not having it in the > first place. Would that be terribly expensive? The behavior of relhaspkey is a legacy thing that we've tolerated only because nothing whatsoever in the backend depends on it at all. I'm not eager to add more equally-ill-defined pg_class columns. regards, tom lane
В списке pgsql-hackers по дате отправления: