On Mon, Sep 15, 2014 at 10:51 PM, Peter Geoghegan <p...@heroku.com> wrote:
> On Mon, Sep 15, 2014 at 8:28 AM, Alexander Korotkov > <aekorot...@gmail.com> wrote: > > some GIN opclasses uses collation-aware comparisons while they don't > need to > > do especially collation-aware comparison. Examples are text[] and hstore > > opclasses. Depending on collation this may make them a much slower. > > I'm glad that I saw how pointless this was with the jsonb GIN default > opclass during development. > > > Rename such opclasses and make them not default. > > Create new default opclasses with bitwise comparison functions. > > Write recommendation to re-create indexes with default opclasses into > > documentation. > > I certainly think this should be fixed if at all possible, but I'm not > sure about this plan. Can we really rename an opclass without > consequence, including having that respected across pg_upgrade? Just rename doesn't seem to be safe. Since pg_upgrade uses pg_dump, all indexes are linked to opclasses using their names. Therefore existed indexes will be linked to new opclasses. It's likely we need to execute SQL script renaming opclasses before pg_upgrade. Another option is to don't rename old opclasses, just create new default opclasses with new names. Bruce, what is your opinion about pg_upgrade? Contrib opclasses would be safe to rename using migration script. ------ With best regards, Alexander Korotkov.
