From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch to support SEMI and ANTI join removal |
Date: | 2014-09-12 09:37:18 |
Message-ID: | CAApHDvr5UPjn-TazxasAs6nzEnzpZtUBCLcX-1fgLAY3fb-mXA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 12, 2014 at 3:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Thu, Sep 11, 2014 at 7:14 AM, David Rowley <dgrowleyml(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ants Aasma | 2014-09-12 09:38:48 | Re: Scaling shared buffer eviction |
Previous Message | Heikki Linnakangas | 2014-09-12 09:28:47 | Re: B-Tree support function number 3 (strxfrm() optimization) |