Re: Patch to support SEMI and ANTI join removal - Mailing list pgsql-hackers

From David Rowley
Subject Re: Patch to support SEMI and ANTI join removal
Date
Msg-id CAApHDvr5UPjn-TazxasAs6nzEnzpZtUBCLcX-1fgLAY3fb-mXA@mail.gmail.com
Whole thread Raw
In response to Re: Patch to support SEMI and ANTI join removal  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Sep 12, 2014 at 3:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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?


I'd imagine not really expensive. I guess I just thought that it would be a good idea to save from having to bother looking in pg_constraint for foreign keys when none exist. The scan uses pg_constraint_conrelid_index so only would ever see the constraints for the rel being cached/loaded.

 
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.


I guess it's certainly not required. It would be easier to add it later if we decided it was a good idea, rather than having to keep it forever and a day if it's next to useless.

I'll remove it from the patch.

Regards

David Rowley

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)
Next
From: Ants Aasma
Date:
Subject: Re: Scaling shared buffer eviction