9

#<#新しい演算子、、、#<=#を使用して、自然な順序（ '1' <'2' <'10' <'11'など）を使用するテキストデータ型に独自の比較演算子を作成しまし#>#た#>=#。

次に、それらを演算子クラスに配置して、次のようにインデックスを作成できるようにします。

CREATE OPERATOR CLASS text_natsort_ops
   FOR TYPE text USING btree AS
   OPERATOR 1  #<#,
   OPERATOR 2  #<=#,
   OPERATOR 3  =,
   OPERATOR 4  #>=#,
   OPERATOR 5  #>#,
   FUNCTION 1  bttext_natsort_cmp(text, text);

ただし、newを使用してインデックスを作成する場合、これは、が使用されるときに行われるため、text_natsort_ops関連するクエリでは使用されません。liketext_pattern_ops

likeインデックスの使用を許可するように演算子クラスを宣言するにはどうすればよいですか？

アップデート：

上記はうまくいくようですので、質問は無効です。私の本当の問題は、次のようなクエリを使用したことでした。

select *
  from mytable
 where number like 'edi%'
 order by number using #<#
 limit 10

また、text_pattern_opsを使用した別のインデックスもありました。これは、はるかに高速に動作するように見えるため、プランナーによって選択されました。ただし、order by ... using新しいopsを使用するインデックスのみが役立つため、他のインデックスは返される結果が多すぎるため、インデックススキャンでlimit句を使用できるようにする必要があります。

4

3 に答える 3

1

これは不可能だと思います。自分が何をしているのか、なぜこれがうまくいかないのかを考える必要があります。プレフィックス検索をサポートするインデックスか、自然数範囲検索をサポートするインデックスのいずれかが必要です。両方をサポートする btree インデックスを持つことはできません。

次のようなものを検討してください。

SELECT * FROM foo
WHERE bar like '10%'
ORDER BY bar USING #>#;

問題は、2 つのインデックスの順序が一致しないことです。LIKE で使用するインデックスは 101、101000、101001 などになりますが、注文のインデックスは 10、11、12、13... 101、102、103、104、105、106、107、108、 109、110、111、...

順序付けには異なる検索順序が必要なため、両方に同じインデックスを使用する方法はありません。ある時点で PostgreSQL がインデックスの物理的順序検索を許可する場合、これは可能になるかもしれませんが、インデックスが論理的順序のみである限り、これはうまくいかないと思います。

于 2013-04-18T10:12:38.200 に答える