RE: [HACKERS] Indexes bug

From: "Jackson, DeJuan" <djackson(at)cpsgroup(dot)com>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: fenix(at)am(dot)ring(dot)ru, pgsql-hackers(at)postgreSQL(dot)org
Subject: RE: [HACKERS] Indexes bug
Date: 1998-08-11 18:34:28
Message-ID: F10BB1FAF801D111829B0060971D839F38DF0D@cpsmail
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I think we now know what is happening in the current cvs tree. The
> optimizer calls op_class to find if there is an pg_opam entry for the
> expression (int4eq), the current index access type(btree), and the
> current index op class(int4_ops).
>
> In the case of oideqint4, there is no pg_amop to match it, and we
> can't
> add extra rows to pg_amop to make it work. I suppose we could try
> adding a amopopr_compat column to pg_amop, and somehow do a lookup on
> that if the first one does not match. Because of the way the system
> caches are structured, we would need a new cache for that extra
> column,
> I think. There must be a better way.
>
Maybe I missed it but why can't we add the extra row to pg_amop.
-DEJ

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-08-11 18:35:57 Re: [HACKERS] Indexes bug
Previous Message Bruce Momjian 1998-08-11 18:33:12 Re: [HACKERS] Latest ecpg patch?