予期せぬ困難に遭遇することなく、CITEXT列をVARCHARに変更できますか？
アプリケーションの特に大きなテーブルのCITEXT列に過剰に行きました。目的のインデックスでルックアップをトリガーする方法がわかりにくいので、これらのいくつかを取り消したいと思います。
私の質問は、大きな困難に直面することなくこれを行うことができるのですか？これを変更した場合、それらのフィールドのインデックスを再構築する必要がありますか？
この方向に移動することによるスペースの増加はありますか？
これらの列では、大文字と小文字を区別しないクエリは必要ありません。
2つの列を前提とするこのテーブルに対するカウントがあり、これらのカウントは1時間以上かかります。テーブルには60列あります。
Postgres 10.6を使用しています。
CITEXTからVARCHARに変更された列がインデックスに含まれている場合に、インデックスを再構築する必要があるかどうかに主に関心があります。
この方向に移動することによるスペースの増加はありますか？
いいえ。citextとtext（またはvarchar）は、ディスクとRAMの同じ領域を占有します。
これらの列では、大文字と小文字を区別しないクエリは必要ありません。
その場合、citextを使用する意味がありません。
2つの列を前提とするこのテーブルに対するカウントがあり、これらのカウントは1時間以上かかります。テーブルには60列あります。
count()は、citextとtext（またはvarchar）の影響をまったく受けません。 「60カラム」は調べるべきものかもしれません。実際にそれらすべてが必要な場合は問題ありませんが、そうですか？そして、適切なデータ型などを使用していますか？.
CITEXTからVARCHARに変更された列がインデックスに含まれている場合に、インデックスを再構築する必要があるかどうかに主に関心があります。
影響を受ける列を含むすべてのインデックスを再構築する必要があります。 （インデックスの削除、タイプの変更、インデックスの再作成。）
個人的には、さまざまな経験をした後はcitextから離れます。