RE: [HACKERS] Indexes bug
От | Jackson, DeJuan |
---|---|
Тема | RE: [HACKERS] Indexes bug |
Дата | |
Msg-id | F10BB1FAF801D111829B0060971D839F38DF0D@cpsmail обсуждение исходный текст |
Ответы |
Re: [HACKERS] Indexes bug
Re: [HACKERS] Indexes bug |
Список | 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
В списке pgsql-hackers по дате отправления: