On Mon, Sep 15, 2014 at 10:51 PM, Peter Geoghegan <pg@heroku.com> wrote:
On Mon, Sep 15, 2014 at 8:28 AM, Alexander Korotkov <aekorotkov@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.
