relhasindex(was RE: [HACKERS] Proposed Changes to PostgreSQL) - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject relhasindex(was RE: [HACKERS] Proposed Changes to PostgreSQL)
Date
Msg-id 000201bf6ea5$1f8a9be0$2801007e@tpf.co.jp
Whole thread Raw
In response to Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce Momjian
> 
> > Bruce Momjian wrote:
> > 
> > > > Well I see that pg_class has columns like "relhasindex". If 
> we added a
> > > > "relhassubclass", the overhead should be unmeasureable.
> > > 
> > > Yes, but how do you keep that accurate?  If I add indexes, then drop
> > > them, does relhasindex go to false. 
> > 
> > I don't know. Does it? 
> 
> Let me add that to the TODO list.
> 
> > 
> > >Could you do that for relhassubclass?
> > 
> > If we made it relnumsubclasses and incremented/decremented on
> > CREATE/DROP, it seems easy in theory.
> 
> Yes, that would work.  Seems hasindex has problems.
>

This posting may be off the point,sorry.

Isn't relhasindex a kind of item that we can live without it ?
I proposed to change the use of this item in [[HACKERS] Index
recreation in vacuum].  Though I have heard no clear objection,
I want to confirm again.  My proposal is as follows.

1) DDL commands don't rely on relhasindex.
2) DML commands don't take indexes into account if   relhasindex is set to false.
3) REINDEX command and vacuum with REINDEX option   sets this flag to false at the beginning and sets it to true   when
recreationof all indexes completed.
 

Comments ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp



pgsql-hackers by date:

Previous
From: Chris Bitmead
Date:
Subject: Re: [HACKERS] how to deal with sparse/to-be populated tables
Next
From: Alfred Perlstein
Date:
Subject: Re: [HACKERS] how to deal with sparse/to-be populated tables