| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, List pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: WIP Join Removal |
| Date: | 2008-09-02 15:35:36 |
| Message-ID: | 14377.1220369736@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Mon, 2008-09-01 at 22:23 +0300, Heikki Linnakangas wrote:
>> Did plan invalidation make it safe to rely on the presence of a unique
>> index for planning decisions?
> My understanding was "Yes" and this case was the specific reason I
> originally wanted to pursue plan invalidation back in 2006.
Yeah, it should work. The theory is that any schema change that could
affect planning should result in broadcasting a relcache inval message
for the table (not just the index, note). I'm pretty confident that
that works for index addition and removal (cf index_update_stats and
index_drop). There might be some situations where we need to force a
relcache inval but don't currently do so --- constraint addition/removal
for instance I'm not too sure about. But that would represent an easily
fixable bug.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-09-02 15:39:29 | Re: rmgr hooks and contrib/rmgr_hook |
| Previous Message | Simon Riggs | 2008-09-02 13:48:44 | Re: WIP Join Removal |