-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathbtree.html
More file actions
1120 lines (1116 loc) · 97.4 KB
/
btree.html
File metadata and controls
1120 lines (1116 loc) · 97.4 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>65.1. B-Treeインデックス</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="indextypes.html" title="第65章 組み込みインデックスアクセスメソッド" /><link rel="next" href="gist.html" title="65.2. GiSTインデックス" /><meta name="viewport" content="width=device-width,initial-scale=1.0" /></head><body id="docContent" class="container-fluid col-10"><div class="other_version"><a href="https://www.postgresql.jp/document/">バージョンごとのドキュメント一覧</a></div><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="4" align="center"><a accesskey="h" href="index.html">PostgreSQL 18.3文書</a></th></tr><tr><td width="10%" align="left"></td><td width="10%" align="left"></td><td width="60%" align="center"><a href="indextypes.html" title="第65章 組み込みインデックスアクセスメソッド">第65章 組み込みインデックスアクセスメソッド</a></td><td width="20%" align="right"><div class="actions"><a class="issue" title="github" href="https://github.com/pgsql-jp/jpug-doc/issues/new?template=bug_report.yml&what-happened=version 18.3 : btree.html">誤訳等の報告
</a></div></td></tr><tr><td width="10%" align="left"><a accesskey="p" href="indextypes.html" title="第65章 組み込みインデックスアクセスメソッド">前へ</a> </td><td width="10%" align="left"><a accesskey="u" href="indextypes.html" title="第65章 組み込みインデックスアクセスメソッド">上へ</a></td><td width="60%" align="center">65.1. B-Treeインデックス</td><td width="20%" align="right"> <a accesskey="n" href="gist.html" title="65.2. GiSTインデックス">次へ</a></td></tr></table><hr /></div><div class="sect1" id="BTREE"><div class="titlepage"><div><div><h2 class="title" style="clear: both">65.1. B-Treeインデックス <a href="#BTREE" class="id_link">#</a></h2></div></div></div><span class="original">
<title>B-Tree Indexes</title>
</span><a id="id-1.10.17.2.2" class="indexterm"></a><a id="id-1.10.17.2.3" class="indexterm"></a><div class="sect2" id="BTREE-INTRO"><div class="titlepage"><div><div><h3 class="title">65.1.1. はじめに <a href="#BTREE-INTRO" class="id_link">#</a></h3></div></div></div><span class="original">
<title>Introduction</title>
</span><p>
<span class="original">
<productname>PostgreSQL</productname> includes an implementation of the
standard <acronym>btree</acronym> (multi-way balanced tree) index data
structure. Any data type that can be sorted into a well-defined linear
order can be indexed by a btree index. The only limitation is that an
index entry cannot exceed approximately one-third of a page (after TOAST
compression, if applicable).
</span>
<span class="productname">PostgreSQL</span>は、標準的な<acronym class="acronym">btree</acronym>（multi-way balanced tree）インデックスデータ構造を実装しています。
明確に定義された線形順にソート可能なデータ型は、すべてbtreeインデックスで索引付できます。
唯一の制限は、一つのインデックスエントリが（適用可能であれば、TOAST圧縮後）ページの約1/3を超えられないことです。
</p><p>
<span class="original">
Because each btree operator class imposes a sort order on its data type,
btree operator classes (or, really, operator families) have come to be
used as <productname>PostgreSQL</productname>'s general representation
and understanding of sorting semantics. Therefore, they've acquired
some features that go beyond what would be needed just to support btree
indexes, and parts of the system that are quite distant from the
btree <acronym>AM</acronym> make use of them.
</span>
btree演算子クラスはそのデータ型がソート順を持つことが必要なので、btree演算子クラス（実際には演算子族）は、<span class="productname">PostgreSQL</span>の一般的表現として、およびソートセマンティクスを理解するものとして利用されてきました。
ですから、単にbtreeインデックスをサポートするだけに必要なもの以上の機能と、btree <acronym class="acronym">AM</acronym>が使用するものからはかけ離れたシステムの部品を備えなければなりません。
</p></div><div class="sect2" id="BTREE-BEHAVIOR"><div class="titlepage"><div><div><h3 class="title">65.1.2. B-Tree演算子クラスの振る舞い <a href="#BTREE-BEHAVIOR" class="id_link">#</a></h3></div></div></div><span class="original">
<title>Behavior of B-Tree Operator Classes</title>
</span><p>
<span class="original">
As shown in <xref linkend="xindex-btree-strat-table"/>, a btree operator
class must provide five comparison operators,
<literal>&lt;</literal>,
<literal>&lt;=</literal>,
<literal>=</literal>,
<literal>&gt;=</literal> and
<literal>&gt;</literal>.
One might expect that <literal>&lt;&gt;</literal> should also be part of
the operator class, but it is not, because it would almost never be
useful to use a <literal>&lt;&gt;</literal> WHERE clause in an index
search. (For some purposes, the planner treats <literal>&lt;&gt;</literal>
as associated with a btree operator class; but it finds that operator via
the <literal>=</literal> operator's negator link, rather than
from <structname>pg_amop</structname>.)
</span>
<a class="xref" href="xindex.html#XINDEX-BTREE-STRAT-TABLE" title="表36.3 B-treeストラテジ">表 36.3</a>で示すように、btree演算子クラスは次の5つの比較演算子を提供しなければなりません。
<code class="literal"><</code>、<code class="literal"><=</code>、<code class="literal">=</code>、<code class="literal">>=</code>、そして<code class="literal">></code>です。
<code class="literal"><></code>も演算子クラスの一部であると期待する方もいるかもしれませんが、そうではありません。
インデックス検索のWHERE句で<code class="literal"><></code>を使うのは、ほとんど常に役に立たないからです。
（ある種の目的のためにプランナは<code class="literal"><></code>をbtree演算子クラスに関連しているものとして扱います。
しかし、プランナは<code class="structname">pg_amop</code>から検索するのではなく<code class="literal">=</code>の否定子リンクから検索します。）
</p><p>
<span class="original">
When several data types share near-identical sorting semantics, their
operator classes can be grouped into an operator family. Doing so is
advantageous because it allows the planner to make deductions about
cross-type comparisons. Each operator class within the family should
contain the single-type operators (and associated support functions)
for its input data type, while cross-type comparison operators and
support functions are <quote>loose</quote> in the family. It is
recommendable that a complete set of cross-type operators be included
in the family, thus ensuring that the planner can represent any
comparison conditions that it deduces from transitivity.
</span>
複数のデータ型がほとんど同じソートセマンティクスを共有している場合、それらの演算子クラスは演算子族にまとめることができます。
そうすることによりプランナが型をまたがる比較を推論できるので、これはメリットがあります。
演算子族内の各演算子クラスは、入力データ型のための単一型演算子（および関連するサポート関数）を含むべきです。
一方、型をまたがる比較演算子とサポート関数は演算子族中で<span class="quote">「<span class="quote">ゆるやか</span>」</span>です。
プランナが推移関係から推論するすべての比較条件を提示できるように、型をまたがる演算子の完全な集合を演算子族に入れておくことをお勧めします。
</p><p>
<span class="original">
There are some basic assumptions that a btree operator family must
satisfy:
</span>
btree演算子族が満たさなければならない基本的な前提条件があります。
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
<span class="original">
An <literal>=</literal> operator must be an equivalence relation; that
is, for all non-null values <replaceable>A</replaceable>,
<replaceable>B</replaceable>, <replaceable>C</replaceable> of the
data type:
</span>
<code class="literal">=</code>演算子は等号関係でなければなりません。
つまり、そのデータ型のすべての非NULL値<em class="replaceable"><code>A</code></em>、<em class="replaceable"><code>B</code></em>、<em class="replaceable"><code>C</code></em>について、
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "><li class="listitem"><p>
<span class="original">
<replaceable>A</replaceable> <literal>=</literal>
<replaceable>A</replaceable> is true
(<firstterm>reflexive law</firstterm>)
</span>
<em class="replaceable"><code>A</code></em> <code class="literal">=</code> <em class="replaceable"><code>A</code></em>が真である（<em class="firstterm">反射律</em>）
</p></li><li class="listitem"><p>
<span class="original">
if <replaceable>A</replaceable> <literal>=</literal>
<replaceable>B</replaceable>,
then <replaceable>B</replaceable> <literal>=</literal>
<replaceable>A</replaceable>
(<firstterm>symmetric law</firstterm>)
</span>
<em class="replaceable"><code>A</code></em> <code class="literal">=</code> <em class="replaceable"><code>B</code></em>なら、<em class="replaceable"><code>B</code></em> <code class="literal">=</code> <em class="replaceable"><code>A</code></em>である（<em class="firstterm">対称律</em>）
</p></li><li class="listitem"><p>
<span class="original">
if <replaceable>A</replaceable> <literal>=</literal>
<replaceable>B</replaceable> and <replaceable>B</replaceable>
<literal>=</literal> <replaceable>C</replaceable>,
then <replaceable>A</replaceable> <literal>=</literal>
<replaceable>C</replaceable>
(<firstterm>transitive law</firstterm>)
</span>
<em class="replaceable"><code>A</code></em> <code class="literal">=</code> <em class="replaceable"><code>B</code></em>かつ<em class="replaceable"><code>B</code></em><code class="literal">=</code> <em class="replaceable"><code>C</code></em>なら、<em class="replaceable"><code>A</code></em> <code class="literal">=</code> <em class="replaceable"><code>C</code></em>である（<em class="firstterm">推移律</em>）
</p></li></ul></div><p>
</p></li><li class="listitem"><p>
<span class="original">
A <literal>&lt;</literal> operator must be a strong ordering relation;
that is, for all non-null values <replaceable>A</replaceable>,
<replaceable>B</replaceable>, <replaceable>C</replaceable>:
</span>
<code class="literal"><</code>は強順序関係でなければなりません。つまり、すべての非NULL値<em class="replaceable"><code>A</code></em>、<em class="replaceable"><code>B</code></em>、<em class="replaceable"><code>C</code></em>に対して、
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "><li class="listitem"><p>
<span class="original">
<replaceable>A</replaceable> <literal>&lt;</literal>
<replaceable>A</replaceable> is false
(<firstterm>irreflexive law</firstterm>)
</span>
<em class="replaceable"><code>A</code></em> <code class="literal"><</code> <em class="replaceable"><code>A</code></em>は偽である（<em class="firstterm">非反射律</em>）
</p></li><li class="listitem"><p>
<span class="original">
if <replaceable>A</replaceable> <literal>&lt;</literal>
<replaceable>B</replaceable>
and <replaceable>B</replaceable> <literal>&lt;</literal>
<replaceable>C</replaceable>,
then <replaceable>A</replaceable> <literal>&lt;</literal>
<replaceable>C</replaceable>
(<firstterm>transitive law</firstterm>)
</span>
<em class="replaceable"><code>A</code></em> <code class="literal"><</code> <em class="replaceable"><code>B</code></em>かつ<em class="replaceable"><code>B</code></em> <code class="literal"><</code> <em class="replaceable"><code>C</code></em>なら、<em class="replaceable"><code>A</code></em> <code class="literal"><</code> <em class="replaceable"><code>C</code></em>である（<em class="firstterm">推移律</em>）
</p></li></ul></div><p>
</p></li><li class="listitem"><p>
<span class="original">
Furthermore, the ordering is total; that is, for all non-null
values <replaceable>A</replaceable>, <replaceable>B</replaceable>:
</span>
更に、順序は全である。すなわち、すべての非NULL値<em class="replaceable"><code>A</code></em>、<em class="replaceable"><code>B</code></em>に対して、
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "><li class="listitem"><p>
<span class="original">
exactly one of <replaceable>A</replaceable> <literal>&lt;</literal>
<replaceable>B</replaceable>, <replaceable>A</replaceable>
<literal>=</literal> <replaceable>B</replaceable>, and
<replaceable>B</replaceable> <literal>&lt;</literal>
<replaceable>A</replaceable> is true
(<firstterm>trichotomy law</firstterm>)
</span>
厳密に<em class="replaceable"><code>A</code></em> <code class="literal"><</code> <em class="replaceable"><code>B</code></em>、<em class="replaceable"><code>A</code></em> <code class="literal">=</code> <em class="replaceable"><code>B</code></em>、<em class="replaceable"><code>B</code></em> <code class="literal"><</code> <em class="replaceable"><code>A</code></em>のうちどれか一つが真（<em class="firstterm">三分律</em>）
</p></li></ul></div><p>
<span class="original">
(The trichotomy law justifies the definition of the comparison support
function, of course.)
</span>
（もちろん、三分律は比較サポート関数の定義を正当化します。）
</p></li></ul></div><p>
<span class="original">
The other three operators are defined in terms of <literal>=</literal>
and <literal>&lt;</literal> in the obvious way, and must act consistently
with them.
</span>
他の3つの演算子は<code class="literal">=</code>と<code class="literal"><</code>に沿って自明に定義され、それらと一貫していなければなりません。
</p><p>
<span class="original">
For an operator family supporting multiple data types, the above laws must
hold when <replaceable>A</replaceable>, <replaceable>B</replaceable>,
<replaceable>C</replaceable> are taken from any data types in the family.
The transitive laws are the trickiest to ensure, as in cross-type
situations they represent statements that the behaviors of two or three
different operators are consistent.
As an example, it would not work to put <type>float8</type>
and <type>numeric</type> into the same operator family, at least not with
the current semantics that <type>numeric</type> values are converted
to <type>float8</type> for comparison to a <type>float8</type>. Because
of the limited accuracy of <type>float8</type>, this means there are
distinct <type>numeric</type> values that will compare equal to the
same <type>float8</type> value, and thus the transitive law would fail.
</span>
複数のデータ型をサポートする演算子族について、演算子族中のデータ型であるどんな<em class="replaceable"><code>A</code></em>、<em class="replaceable"><code>B</code></em>、<em class="replaceable"><code>C</code></em>も上記の法則を満たさなければなりません。
型をまたがる場合、2つまたは3つの異なる演算子の動作が一貫している必要があるため、推移律を満たすことが最も困難です。
例をあげると、少なくとも<code class="type">float8</code>と比較するために<code class="type">numeric</code>値を<code class="type">float8</code>に変換する現在の意味論のもとでは、<code class="type">float8</code>と<code class="type">numeric</code>を同じ演算子族に加えるのはうまくいかないでしょう。
<code class="type">float8</code>の精度に限りがあるからです。
これは同じ<code class="type">float8</code>値に対して等号比較する複数の異なる<code class="type">numeric</code>値が存在することを意味し、したがって推移律は満たされません。
</p><p>
<span class="original">
Another requirement for a multiple-data-type family is that any implicit
or binary-coercion casts that are defined between data types included in
the operator family must not change the associated sort ordering.
</span>
複数データ型族に関する別な要件は、演算子族に含まれるデータ型間に定義される暗黙的あるいは二値型強制(binary-coercion)キャストは、関係するソート順を変更してはならないことです。
</p><p>
<span class="original">
It should be fairly clear why a btree index requires these laws to hold
within a single data type: without them there is no ordering to arrange
the keys with. Also, index searches using a comparison key of a
different data type require comparisons to behave sanely across two
data types. The extensions to three or more data types within a family
are not strictly required by the btree index mechanism itself, but the
planner relies on them for optimization purposes.
</span>
単一のデータ型において、btreeインデックスがこれらの法則を守ることを要求するのはかなり明確です。
これらの法則なしにはキー並べる順序がなくなってしまうからです。
また、異なるデータ型の比較キーを使うインデックス検索では、2つのデータ型またがる比較が正常に動作することが必要です。
演算子族中で3つ以上のデータ型に対する拡張はbtreeインデックスの機構自体では要求されませんが、プランナは最適化の目的でそれらに依存します。
</p></div><div class="sect2" id="BTREE-SUPPORT-FUNCS"><div class="titlepage"><div><div><h3 class="title">65.1.3. B-Treeサポート関数 <a href="#BTREE-SUPPORT-FUNCS" class="id_link">#</a></h3></div></div></div><span class="original">
<title>B-Tree Support Functions</title>
</span><p>
<span class="original">
As shown in <xref linkend="xindex-btree-support-table"/>, btree defines
one required and five optional support functions. The six
user-defined methods are:
</span>
<a class="xref" href="xindex.html#XINDEX-BTREE-SUPPORT-TABLE" title="表36.9 B-treeサポート関数">表 36.9</a>で示すように、btreeでは一つの必須サポート関数と、5つの省略可能なサポート関数を定義します。
6つのユーザ定義メソッドは以下の通りです。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="function">order</code></span></dt><dd><p>
<span class="original">
For each combination of data types that a btree operator family
provides comparison operators for, it must provide a comparison
support function, registered in
<structname>pg_amproc</structname> with support function number 1
and
<structfield>amproclefttype</structfield>/<structfield>amprocrighttype</structfield>
equal to the left and right data types for the comparison (i.e.,
the same data types that the matching operators are registered
with in <structname>pg_amop</structname>). The comparison
function must take two non-null values
<replaceable>A</replaceable> and <replaceable>B</replaceable> and
return an <type>int32</type> value that is
<literal>&lt;</literal> <literal>0</literal>,
<literal>0</literal>, or <literal>&gt;</literal>
<literal>0</literal> when <replaceable>A</replaceable>
<literal>&lt;</literal> <replaceable>B</replaceable>,
<replaceable>A</replaceable> <literal>=</literal>
<replaceable>B</replaceable>, or <replaceable>A</replaceable>
<literal>&gt;</literal> <replaceable>B</replaceable>,
respectively. A null result is disallowed: all values of the
data type must be comparable. See
<filename>src/backend/access/nbtree/nbtcompare.c</filename> for
examples.
</span>
btreeの演算子族が比較演算子を提供する各データ型の組み合わせに対して、比較サポート関数を提供しなければなりません。それらはサポート関数1番で<code class="structname">pg_amproc</code>に、また、比較での左右のデータ型と等しい<code class="structfield">amproclefttype</code>/<code class="structfield">amprocrighttype</code>に、登録されます（すなわち、<code class="structname">pg_amop</code>に登録されている演算子が対応するものと同じデータ型です）。
比較関数は2つの非NULL値<em class="replaceable"><code>A</code></em>と<em class="replaceable"><code>B</code></em>を取り、
<em class="replaceable"><code>A</code></em> <code class="literal"><</code> <em class="replaceable"><code>B</code></em>、<em class="replaceable"><code>A</code></em> <code class="literal">=</code> <em class="replaceable"><code>B</code></em>、または、<em class="replaceable"><code>A</code></em> <code class="literal">></code> <em class="replaceable"><code>B</code></em>であるときにそれぞれ、<code class="literal"><</code> <code class="literal">0</code>、<code class="literal">0</code>、または、<code class="literal">></code> <code class="literal">0</code>である<code class="type">int32</code>の値を返さなければなりません。
NULLを返すことは許されず、データ型の全ての値は比較可能でなければなりません。
例として<code class="filename">src/backend/access/nbtree/nbtcompare.c</code>を参照してください。
</p><p>
<span class="original">
If the compared values are of a collatable data type, the
appropriate collation OID will be passed to the comparison
support function, using the standard
<function>PG_GET_COLLATION()</function> mechanism.
</span>
比較される値が照合順序が適用可能なデータ型のものである場合、比較サポート関数に適切な照合順序のOIDが渡され、標準の<code class="function">PG_GET_COLLATION()</code>機構が使用されます。
</p></dd><dt><span class="term"><code class="function">sortsupport</code></span></dt><dd><p>
<span class="original">
Optionally, a btree operator family may provide <firstterm>sort
support</firstterm> function(s), registered under support
function number 2. These functions allow implementing
comparisons for sorting purposes in a more efficient way than
naively calling the comparison support function. The APIs
involved in this are defined in
<filename>src/include/utils/sortsupport.h</filename>.
</span>
任意で、btree演算子族は<em class="firstterm">ソートサポート</em>関数を提供してもよいです。これはサポート関数2番で登録されます。
この関数は、素朴に比較サポート関数を呼び出すよりも、ソート目的により効果的な方法での比較の実装を可能にします。
これに関するAPIは<code class="filename">src/include/utils/sortsupport.h</code>で定義されています。
</p></dd><dt><span class="term"><code class="function">in_range</code></span></dt><dd><a id="id-1.10.17.2.6.3.3.2.1" class="indexterm"></a><a id="id-1.10.17.2.6.3.3.2.2" class="indexterm"></a><a id="id-1.10.17.2.6.3.3.2.3" class="indexterm"></a><a id="id-1.10.17.2.6.3.3.2.4" class="indexterm"></a><p>
<span class="original">
Optionally, a btree operator family may provide
<firstterm>in_range</firstterm> support function(s), registered
under support function number 3. These are not used during btree
index operations; rather, they extend the semantics of the
operator family so that it can support window clauses containing
the <literal>RANGE</literal> <replaceable>offset</replaceable>
<literal>PRECEDING</literal> and <literal>RANGE</literal>
<replaceable>offset</replaceable> <literal>FOLLOWING</literal>
frame bound types (see <xref
linkend="syntax-window-functions"/>). Fundamentally, the extra
information provided is how to add or subtract an
<replaceable>offset</replaceable> value in a way that is
compatible with the family's data ordering.
</span>
任意で、btree演算子族は<em class="firstterm">in_range</em>サポート関数を提供してもよいです。これはサポート関数3番に登録されます。
これはbtreeインデックス操作中には使われません。そうではなく、演算子族のセマンティクスを<code class="literal">RANGE</code> <em class="replaceable"><code>offset</code></em> <code class="literal">PRECEDING</code>と<code class="literal">RANGE</code> <em class="replaceable"><code>offset</code></em> <code class="literal">FOLLOWING</code>フレーム境界タイプ（<a class="xref" href="sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS" title="4.2.8. ウィンドウ関数呼び出し">4.2.8</a>を参照）を含むWINDOW句に対応できるように拡張します。
基本的には、提供される拡張情報はどのように演算子族のデータ並び順と互換性のある方法で<em class="replaceable"><code>offset</code></em>値を足すか引くかです。
</p><p>
<span class="original">
An <function>in_range</function> function must have the signature
</span>
<code class="function">in_range</code>関数は以下のシグネチャを持たなければなりません。
</p><pre class="synopsis">
in_range(<em class="replaceable"><code>val</code></em> type1, <em class="replaceable"><code>base</code></em> type1, <em class="replaceable"><code>offset</code></em> type2, <em class="replaceable"><code>sub</code></em> bool, <em class="replaceable"><code>less</code></em> bool)
returns bool
</pre><p>
<span class="original">
<replaceable>val</replaceable> and
<replaceable>base</replaceable> must be of the same type, which
is one of the types supported by the operator family (i.e., a
type for which it provides an ordering). However,
<replaceable>offset</replaceable> could be of a different type,
which might be one otherwise unsupported by the family. An
example is that the built-in <literal>time_ops</literal> family
provides an <function>in_range</function> function that has
<replaceable>offset</replaceable> of type <type>interval</type>.
A family can provide <function>in_range</function> functions for
any of its supported types and one or more
<replaceable>offset</replaceable> types. Each
<function>in_range</function> function should be entered in
<structname>pg_amproc</structname> with
<structfield>amproclefttype</structfield> equal to
<type>type1</type> and <structfield>amprocrighttype</structfield>
equal to <type>type2</type>.
</span>
<em class="replaceable"><code>val</code></em>と<em class="replaceable"><code>base</code></em>は同じ型でなければならず、これは演算子族でサポートされる型の一つ（すなわち、並び順を提供する対象の型）です。
しかしながら、<em class="replaceable"><code>offset</code></em>は異なる型のものでも可能です。それは演算子族でサポートされないものでもよいです。
例としては、組み込みの<code class="literal">time_ops</code>族が<code class="type">interval</code>型の<em class="replaceable"><code>offset</code></em>を持つ<code class="function">in_range</code>関数を提供しています。
演算子族は、任意のサポートされる型と一つまたは複数の<em class="replaceable"><code>offset</code></em>型に対する<code class="function">in_range</code>関数を提供できます。
各<code class="function">in_range</code>関数は、<code class="structname">pg_amproc</code>に<code class="type">type1</code>と等しい<code class="structfield">amproclefttype</code>と<code class="type">type2</code>に等しい<code class="structfield">amprocrighttype</code>で登録されるべきです。
</p><p>
<span class="original">
The essential semantics of an <function>in_range</function>
function depend on the two Boolean flag parameters. It should
add or subtract <replaceable>base</replaceable> and
<replaceable>offset</replaceable>, then compare
<replaceable>val</replaceable> to the result, as follows:
</span>
<code class="function">in_range</code>関数の本質的なセマンティクスは2つのBooleanフラグパラメータに依存します。
これは以下のように、<em class="replaceable"><code>base</code></em>に<em class="replaceable"><code>offset</code></em>を加算または減算して、それから<em class="replaceable"><code>val</code></em>を結果と比較すべきです。
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
<span class="original">
if <literal>!</literal><replaceable>sub</replaceable> and
<literal>!</literal><replaceable>less</replaceable>, return
<replaceable>val</replaceable> <literal>&gt;=</literal>
(<replaceable>base</replaceable> <literal>+</literal>
<replaceable>offset</replaceable>)
</span>
<code class="literal">!</code><em class="replaceable"><code>sub</code></em>かつ
<code class="literal">!</code><em class="replaceable"><code>less</code></em>であるなら、
<em class="replaceable"><code>val</code></em> <code class="literal">>=</code>
(<em class="replaceable"><code>base</code></em> <code class="literal">+</code>
<em class="replaceable"><code>offset</code></em>)を返します
</p></li><li class="listitem"><p>
<span class="original">
if <literal>!</literal><replaceable>sub</replaceable> and
<replaceable>less</replaceable>, return
<replaceable>val</replaceable> <literal>&lt;=</literal>
(<replaceable>base</replaceable> <literal>+</literal>
<replaceable>offset</replaceable>)
</span>
<code class="literal">!</code><em class="replaceable"><code>sub</code></em>かつ
<em class="replaceable"><code>less</code></em>であるなら、
<em class="replaceable"><code>val</code></em> <code class="literal"><=</code>
(<em class="replaceable"><code>base</code></em> <code class="literal">+</code>
<em class="replaceable"><code>offset</code></em>)を返します
</p></li><li class="listitem"><p>
<span class="original">
if <replaceable>sub</replaceable> and
<literal>!</literal><replaceable>less</replaceable>, return
<replaceable>val</replaceable> <literal>&gt;=</literal>
(<replaceable>base</replaceable> <literal>-</literal>
<replaceable>offset</replaceable>)
</span>
<em class="replaceable"><code>sub</code></em>かつ
<code class="literal">!</code><em class="replaceable"><code>less</code></em>であるなら、
<em class="replaceable"><code>val</code></em> <code class="literal">>=</code>
(<em class="replaceable"><code>base</code></em> <code class="literal">-</code>
<em class="replaceable"><code>offset</code></em>)を返します
</p></li><li class="listitem"><p>
<span class="original">
if <replaceable>sub</replaceable> and
<replaceable>less</replaceable>, return
<replaceable>val</replaceable> <literal>&lt;=</literal>
(<replaceable>base</replaceable> <literal>-</literal>
<replaceable>offset</replaceable>)
</span>
<em class="replaceable"><code>sub</code></em>かつ
<em class="replaceable"><code>less</code></em>であるなら、
<em class="replaceable"><code>val</code></em> <code class="literal"><=</code>
(<em class="replaceable"><code>base</code></em> <code class="literal">-</code>
<em class="replaceable"><code>offset</code></em>)を返します
</p></li></ul></div><p>
<span class="original">
Before doing so, the function should check the sign of
<replaceable>offset</replaceable>: if it is less than zero, raise
error
<literal>ERRCODE_INVALID_PRECEDING_OR_FOLLOWING_SIZE</literal>
(22013) with error text like <quote>invalid preceding or
following size in window function</quote>. (This is required by
the SQL standard, although nonstandard operator families might
perhaps choose to ignore this restriction, since there seems to
be little semantic necessity for it.) This requirement is
delegated to the <function>in_range</function> function so that
the core code needn't understand what <quote>less than
zero</quote> means for a particular data type.
</span>
このように実行する前に、本関数は、<em class="replaceable"><code>offset</code></em>の符号を検査すべきです。
すなわち、負であったなら、エラー<code class="literal">ERRCODE_INVALID_PRECEDING_OR_FOLLOWING_SIZE</code>(22013)、エラー文面としては<span class="quote">「<span class="quote">invalid preceding or following size in window function(ウィンドウ関数で先行または後続のサイズが不正です)</span>」</span>などを出すことです。
（意味上の必要性が乏しいと見られることから非標準の演算子族はこの制限を無視することを選ぶかもしれませんが、これは標準SQLで必要とされています。）
中核コードが特定のデータ型における<span class="quote">「<span class="quote">ゼロより小さい</span>」</span>ことの意味を理解しなくても良いように、この要件は<code class="function">in_range</code>関数に委託されます。
</p><p>
<span class="original">
An additional expectation is that <function>in_range</function>
functions should, if practical, avoid throwing an error if
<replaceable>base</replaceable> <literal>+</literal>
<replaceable>offset</replaceable> or
<replaceable>base</replaceable> <literal>-</literal>
<replaceable>offset</replaceable> would overflow. The correct
comparison result can be determined even if that value would be
out of the data type's range. Note that if the data type
includes concepts such as <quote>infinity</quote> or
<quote>NaN</quote>, extra care may be needed to ensure that
<function>in_range</function>'s results agree with the normal
sort order of the operator family.
</span>
さらに期待されることは、<code class="function">in_range</code>関数は、実用的には、<em class="replaceable"><code>base</code></em> <code class="literal">+</code> <em class="replaceable"><code>offset</code></em>や<em class="replaceable"><code>base</code></em> <code class="literal">-</code> <em class="replaceable"><code>offset</code></em>がオーバーフローする場合にエラーを投げるのを避けるべきです。
たとえ値がデータ型の範囲を超えたとしても正しい比較結果は決定できます。
データ型が<span class="quote">「<span class="quote">infinity</span>」</span>や<span class="quote">「<span class="quote">NaN</span>」</span>などの概念を含む場合には、<code class="function">in_range</code>の結果が演算子族の通常のソート順序と一致するように特別な対応が必要となることに注意してください。
</p><p>
<span class="original">
The results of the <function>in_range</function> function must be
consistent with the sort ordering imposed by the operator family.
To be precise, given any fixed values of
<replaceable>offset</replaceable> and
<replaceable>sub</replaceable>, then:
</span>
<code class="function">in_range</code>関数の結果は、演算子族で規定されるソート順序と整合していなければなりません。
正確には、与えられた任意の<em class="replaceable"><code>offset</code></em>と<em class="replaceable"><code>sub</code></em>の固定値については以下のようになります。
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
<span class="original">
If <function>in_range</function> with
<replaceable>less</replaceable> = true is true for some
<replaceable>val1</replaceable> and
<replaceable>base</replaceable>, it must be true for every
<replaceable>val2</replaceable> <literal>&lt;=</literal>
<replaceable>val1</replaceable> with the same
<replaceable>base</replaceable>.
</span>
<em class="replaceable"><code>less</code></em> = trueの<code class="function">in_range</code>がいくつかの<em class="replaceable"><code>val1</code></em>と<em class="replaceable"><code>base</code></em>に対して真であるなら、同じ<em class="replaceable"><code>base</code></em>の全ての<em class="replaceable"><code>val2</code></em> <code class="literal"><=</code> <em class="replaceable"><code>val1</code></em>に対して真でなければなりません。
</p></li><li class="listitem"><p>
<span class="original">
If <function>in_range</function> with
<replaceable>less</replaceable> = true is false for some
<replaceable>val1</replaceable> and
<replaceable>base</replaceable>, it must be false for every
<replaceable>val2</replaceable> <literal>&gt;=</literal>
<replaceable>val1</replaceable> with the same
<replaceable>base</replaceable>.
</span>
<em class="replaceable"><code>less</code></em> = trueの<code class="function">in_range</code>が、いくつかの<em class="replaceable"><code>val1</code></em>と<em class="replaceable"><code>base</code></em>に対して偽であるなら、同じ<em class="replaceable"><code>base</code></em>の全ての<em class="replaceable"><code>val2</code></em> <code class="literal">>=</code> <em class="replaceable"><code>val1</code></em>に対して偽でなければなりません。
</p></li><li class="listitem"><p>
<span class="original">
If <function>in_range</function> with
<replaceable>less</replaceable> = true is true for some
<replaceable>val</replaceable> and
<replaceable>base1</replaceable>, it must be true for every
<replaceable>base2</replaceable> <literal>&gt;=</literal>
<replaceable>base1</replaceable> with the same
<replaceable>val</replaceable>.
</span>
<em class="replaceable"><code>less</code></em> = trueの<code class="function">in_range</code>がいくつかの<em class="replaceable"><code>val</code></em>と<em class="replaceable"><code>base1</code></em>に対して真であるなら、同じ<em class="replaceable"><code>val</code></em>の全ての<em class="replaceable"><code>base2</code></em> <code class="literal">>=</code> <em class="replaceable"><code>base1</code></em>に対して真でなければなりません。
</p></li><li class="listitem"><p>
<span class="original">
If <function>in_range</function> with
<replaceable>less</replaceable> = true is false for some
<replaceable>val</replaceable> and
<replaceable>base1</replaceable>, it must be false for every
<replaceable>base2</replaceable> <literal>&lt;=</literal>
<replaceable>base1</replaceable> with the same
<replaceable>val</replaceable>.
</span>
<em class="replaceable"><code>less</code></em> = trueの<code class="function">in_range</code>が一部の<em class="replaceable"><code>val</code></em>と<em class="replaceable"><code>base1</code></em>に対して偽であるなら、同じ<em class="replaceable"><code>val</code></em>の全ての<em class="replaceable"><code>base2</code></em> <code class="literal"><=</code> <em class="replaceable"><code>base1</code></em>に対して偽でなければなりません。
</p></li></ul></div><p>
<span class="original">
Analogous statements with inverted conditions hold when
<replaceable>less</replaceable> = false.
</span>
<em class="replaceable"><code>less</code></em> = falseのときには、逆条件の類似した命題が適用できます。
</p><p>
<span class="original">
If the type being ordered (<type>type1</type>) is collatable, the
appropriate collation OID will be passed to the
<function>in_range</function> function, using the standard
PG_GET_COLLATION() mechanism.
</span>
整列しようとしている型(<code class="type">type1</code>)が照合可能であるなら、標準のPG_GET_COLLATION()機構を使って、<code class="function">in_range</code>関数に適切な照合順序のOIDが渡されます。
</p><p>
<span class="original">
<function>in_range</function> functions need not handle NULL
inputs, and typically will be marked strict.
</span>
<code class="function">in_range</code>関数は、通例STRICTと印付けされ、NULL入力を処理する必要がありません。
</p></dd><dt><span class="term"><code class="function">equalimage</code></span></dt><dd><p>
<span class="original">
Optionally, a btree operator family may provide
<function>equalimage</function> (<quote>equality implies image
equality</quote>) support functions, registered under support
function number 4. These functions allow the core code to
determine when it is safe to apply the btree deduplication
optimization. Currently, <function>equalimage</function>
functions are only called when building or rebuilding an index.
</span>
省略可能ですが、btree演算子族は<code class="function">equalimage</code> (<span class="quote">「<span class="quote">イメージ等価を意味する等価</span>」</span>)サポート関数を提供してもよいです。これはサポート関数4番で登録されます。
この関数は、中核コードがbtree重複排除の最適化を適用するのが安全かを決定できるようにします。
今のところ、<code class="function">equalimage</code>関数はインデックスの構築または再構築時にのみ呼び出されます。
</p><p>
<span class="original">
An <function>equalimage</function> function must have the
signature
</span>
<code class="function">equalimage</code>関数は以下のシグネチャを持たなければなりません。
</p><pre class="synopsis">
equalimage(<em class="replaceable"><code>opcintype</code></em> <code class="type">oid</code>) returns bool
</pre><p>
<span class="original">
The return value is static information about an operator class
and collation. Returning <literal>true</literal> indicates that
the <function>order</function> function for the operator class is
guaranteed to only return <literal>0</literal> (<quote>arguments
are equal</quote>) when its <replaceable>A</replaceable> and
<replaceable>B</replaceable> arguments are also interchangeable
without any loss of semantic information. Not registering an
<function>equalimage</function> function or returning
<literal>false</literal> indicates that this condition cannot be
assumed to hold.
</span>
戻り値は演算子クラスと照合順序についての静的な情報です。
<code class="literal">true</code>を返すことは、<em class="replaceable"><code>A</code></em>および<em class="replaceable"><code>B</code></em>引数が何らセマンティック情報を損失すること無しに交換可能でもあるとき、演算子クラスに対する<code class="function">order</code>関数が<code class="literal">0</code>（<span class="quote">「<span class="quote">引数が等しい</span>」</span>）だけを返すことが保証されていることを示します。
<code class="function">equalimage</code>関数が登録されていなかったり、<code class="literal">false</code>を返すことは、この条件は守られないであろうことを示します。
</p><p>
<span class="original">
The <replaceable>opcintype</replaceable> argument is the
<literal><structname>pg_type</structname>.oid</literal> of the
data type that the operator class indexes. This is a convenience
that allows reuse of the same underlying
<function>equalimage</function> function across operator classes.
If <replaceable>opcintype</replaceable> is a collatable data
type, the appropriate collation OID will be passed to the
<function>equalimage</function> function, using the standard
<function>PG_GET_COLLATION()</function> mechanism.
</span>
<em class="replaceable"><code>opcintype</code></em>引数は演算子クラスタがインデックスを作るデータ型の<code class="literal"><code class="structname">pg_type</code>.oid</code>です。
これは同じ基となる<code class="function">equalimage</code>関数を演算子クラスを横断して再利用できるようになる利便性があります。
<em class="replaceable"><code>opcintype</code></em>が照合可能なデータ型である場合には、適切な照合順序のOIDが、標準の<code class="function">PG_GET_COLLATION()</code>機構を使って、<code class="function">equalimage</code>関数に渡されます。
</p><p>
<span class="original">
As far as the operator class is concerned, returning
<literal>true</literal> indicates that deduplication is safe (or
safe for the collation whose OID was passed to its
<function>equalimage</function> function). However, the core
code will only deem deduplication safe for an index when
<emphasis>every</emphasis> indexed column uses an operator class
that registers an <function>equalimage</function> function, and
each function actually returns <literal>true</literal> when
called.
</span>
演算子クラスに関する限り、<code class="literal">true</code>を返すことは、重複排除が安全（あるいは<code class="function">equalimage</code>関数に渡されたOIDの照合順序について安全）であることを示します。
しかしながら、コアコードは、<span class="emphasis"><em>全ての</em></span>インデックス列が<code class="function">equalimage</code>関数を登録する演算子クラスを使っていて、各関数が呼ばれたとき実際に<code class="literal">true</code>を返すときに、そのインデックスに対して重複排除を安全と見做すだけです。
</p><p>
<span class="original">
Image equality is <emphasis>almost</emphasis> the same condition
as simple bitwise equality. There is one subtle difference: When
indexing a varlena data type, the on-disk representation of two
image equal datums may not be bitwise equal due to inconsistent
application of <acronym>TOAST</acronym> compression on input.
Formally, when an operator class's
<function>equalimage</function> function returns
<literal>true</literal>, it is safe to assume that the
<literal>datum_image_eq()</literal> C function will always agree
with the operator class's <function>order</function> function
(provided that the same collation OID is passed to both the
<function>equalimage</function> and <function>order</function>
functions).
</span>
イメージ等価は単純にビット毎に等しいことと<span class="emphasis"><em>ほとんど</em></span>同じ条件です。
一点微妙な違いがあります。varlenaデータ型にインデックス作成するとき、入力時の一貫性のない<acronym class="acronym">TOAST</acronym>圧縮の適用のために、同じdatumの二つのイメージのディスク上の表現はビット毎には等しくないかもしれません。
形式的には、演算子クラスの<code class="function">equalimage</code>関数が<code class="literal">true</code>を返すときには、<code class="literal">datum_image_eq()</code> C関数が常に演算子クラスの<code class="function">order</code>関数と一致すると想定して安全でした（同じ照合順序のOIDが<code class="function">equalimage</code>と<code class="function">order</code>の両関数に渡されるとして）。
</p><p>
<span class="original">
The core code is fundamentally unable to deduce anything about
the <quote>equality implies image equality</quote> status of an
operator class within a multiple-data-type family based on
details from other operator classes in the same family. Also, it
is not sensible for an operator family to register a cross-type
<function>equalimage</function> function, and attempting to do so
will result in an error. This is because <quote>equality implies
image equality</quote> status does not just depend on
sorting/equality semantics, which are more or less defined at the
operator family level. In general, the semantics that one
particular data type implements must be considered separately.
</span>
コアコードは基本的に、複数データ型の族の中の演算子クラスの<span class="quote">「<span class="quote">等価性がイメージ等価性を含む</span>」</span>状態について、同族の他の演算子クラスの詳細に基づいた、いかなる推測もできません。
また、ある演算子族が型にまたがって<code class="function">equalimage</code>関数を登録していることを認識できず、そのような試みはエラーになります。
これは<span class="quote">「<span class="quote">等価性がイメージ等価性を含む</span>」</span>状態は、演算子族の階層でおおむね定義されている、ソートと等価性のセマンティクスに依存しているだけでは無いためです。
一般に、ある特定データ型の実装によるセマンティクスは別個に考慮されなければなりません。
</p><p>
<span class="original">
The convention followed by the operator classes included with the
core <productname>PostgreSQL</productname> distribution is to
register a stock, generic <function>equalimage</function>
function. Most operator classes register
<function>btequalimage()</function>, which indicates that
deduplication is safe unconditionally. Operator classes for
collatable data types such as <type>text</type> register
<function>btvarstrequalimage()</function>, which indicates that
deduplication is safe with deterministic collations. Best
practice for third-party extensions is to register their own
custom function to retain control.
</span>
<span class="productname">PostgreSQL</span>のコア配布物に含まれる演算子クラスが従う慣習は、標準品、すなわち、一般的な<code class="function">equalimage</code>関数を登録することです。
大部分の演算子クラスタは<code class="function">btequalimage()</code>を登録しています。これは重複排除が無条件に安全であることを示しています。
<code class="type">text</code>などの照合可能なデータ型に対する演算子クラスは<code class="function">btvarstrequalimage()</code>を登録します。これは決定的な照合順序では重複排除が安全であることを示します。
サードパーティ拡張におけるベストプラクティスは制御を保つためにそれら自身のカスタム関数を登録することです。
</p></dd><dt><span class="term"><code class="function">options</code></span></dt><dd><p>
<span class="original">
Optionally, a B-tree operator family may provide
<function>options</function> (<quote>operator class specific
options</quote>) support functions, registered under support
function number 5. These functions define a set of user-visible
parameters that control operator class behavior.
</span>
省略可能ですが、B-treeの演算子族は<code class="function">options</code>（<span class="quote">「<span class="quote">演算子クラス固有オプション</span>」</span>）サポート関数を提供してもよいです。これはサポート関数5番に登録されます。
この関数はユーザに見える演算子クラスの振る舞いを制御するパラメータの集合を定義します。
</p><p>
<span class="original">
An <function>options</function> support function must have the
signature
</span>
<code class="function">options</code>サポート関数は以下のシグネチャを持たなければなりません。
</p><pre class="synopsis">
options(<em class="replaceable"><code>relopts</code></em> <code class="type">local_relopts *</code>) returns void
</pre><p>
<span class="original">
The function is passed a pointer to a <structname>local_relopts</structname>
struct, which needs to be filled with a set of operator class
specific options. The options can be accessed from other support
functions using the <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
<literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
</span>
関数には<code class="structname">local_relopts</code>構造体へのポインタが渡されます。ここには演算子クラス固有のオプションの集合が書かれている必要があります。
このオプションには<code class="literal">PG_HAS_OPCLASS_OPTIONS()</code>および<code class="literal">PG_GET_OPCLASS_OPTIONS()</code>マクロを使って他のサポート関数からアクセスが可能です。
</p><p>
<span class="original">
Currently, no B-Tree operator class has an <function>options</function>
support function. B-tree doesn't allow flexible representation of keys
like GiST, SP-GiST, GIN and BRIN do. So, <function>options</function>
probably doesn't have much application in the current B-tree index
access method. Nevertheless, this support function was added to B-tree
for uniformity, and will probably find uses during further
evolution of B-tree in <productname>PostgreSQL</productname>.
</span>
今のところ、<code class="function">options</code>サポート関数を持ったB-Treeの演算子クラスはありません。
B-treeはGiST、SP-GiST、GINおよびBRINで行われているような柔軟なキーの表現を許していません。
そのため、おそらくは<code class="function">options</code>が現在のB-treeインデックスアクセスメソッドで多数適用されることはありません。
それでも、統一性のためにサポート関数がB-treeに追加されました。おそらく<span class="productname">PostgreSQL</span>でのB-treeの更なる進化の過程で使用法を見つけ出すでしょう。
</p></dd><dt><span class="term"><code class="function">skipsupport</code></span></dt><dd><p>
<span class="original">
Optionally, a btree operator family may provide a <firstterm>skip
support</firstterm> function, registered under support function number 6.
These functions give the B-tree code a way to iterate through every
possible value that can be represented by an operator class's underlying
input type, in key space order. This is used by the core code when it
applies the skip scan optimization. The APIs involved in this are
defined in <filename>src/include/utils/skipsupport.h</filename>.
</span>
省略可能ですが、btree演算子族は<em class="firstterm">スキップサポート</em>関数を提供してもよいです。これはサポート関数6番に登録されます。
この関数は、B-treeコードに対して、演算子クラスの基となる入力型で表すことができるすべての値を、キー空間の順序で繰り返し処理する方法を提供します。
これは、スキップスキャンを最適化するときにコアコードによって使用されます。
これに関するAPIは<code class="filename">src/include/utils/skipsupport.h</code>で定義されています。
</p><p>
<span class="original">
Operator classes that do not provide a skip support function are still
eligible to use skip scan. The core code can still use its fallback
strategy, though that might be suboptimal for some discrete types. It
usually doesn't make sense (and may not even be feasible) for operator
classes on continuous types to provide a skip support function.
</span>
スキップサポート関数を提供しない演算子クラスでも、スキップスキャンを使用できます。
コアコードでも代替の戦略を使用できますが、一部の離散型では最適ではない場合があります。
通常、連続型の演算子クラスがスキップサポート関数を提供することは意味がありません（実行不可能な場合もあります）。
</p><p>
<span class="original">
It is not sensible for an operator family to register a cross-type
<function>skipsupport</function> function, and attempting to do so will
result in an error. This is because determining the next indexable value
must happen by incrementing a value copied from an index tuple. The
values generated must all be of the same underlying data type (the
<quote>skipped</quote> index column's opclass input type).
</span>
演算子族が型をまたがる<code class="function">skipsupport</code>関数を登録するのは賢明ではなく、登録しようとするとエラーになります。
これは、次のインデックス可能な値を決定するには、インデックスタプルからコピーされた値を増分する必要があるためです。
生成される値はすべて、基になるデータ型 (<span class="quote">「<span class="quote">スキップされた</span>」</span>インデックス列の演算子クラス入力型) が同じである必要があります。
</p></dd></dl></div></div><div class="sect2" id="BTREE-IMPLEMENTATION"><div class="titlepage"><div><div><h3 class="title">65.1.4. 実装 <a href="#BTREE-IMPLEMENTATION" class="id_link">#</a></h3></div></div></div><span class="original">
<title>Implementation</title>
</span><p>
<span class="original">
This section covers B-Tree index implementation details that may be
of use to advanced users. See
<filename>src/backend/access/nbtree/README</filename> in the source
distribution for a much more detailed, internals-focused description
of the B-Tree implementation.
</span>
本節では、上級ユーザに役立つかもしれない、B-Treeインデックスの実装の詳細について説明します。
更なる詳細、B-Tree実装の内部に焦点をあてた記述については、ソース配布物の<code class="filename">src/backend/access/nbtree/README</code>を参照してください。
</p><div class="sect3" id="BTREE-STRUCTURE"><div class="titlepage"><div><div><h4 class="title">65.1.4.1. B-Treeの構造 <a href="#BTREE-STRUCTURE" class="id_link">#</a></h4></div></div></div><span class="original">
<title>B-Tree Structure</title>
</span><p>
<span class="original">
<productname>PostgreSQL</productname> B-Tree indexes are
multi-level tree structures, where each level of the tree can be
used as a doubly-linked list of pages. A single metapage is stored
in a fixed position at the start of the first segment file of the
index. All other pages are either leaf pages or internal pages.
Leaf pages are the pages on the lowest level of the tree. All
other levels consist of internal pages. Each leaf page contains
tuples that point to table rows. Each internal page contains
tuples that point to the next level down in the tree. Typically,
over 99% of all pages are leaf pages. Both internal pages and leaf
pages use the standard page format described in <xref
linkend="storage-page-layout"/>.
</span>
<span class="productname">PostgreSQL</span>のB-Treeインデックスは複数階層のツリー構造で、ツリーの各階層はページの双方向連結リストとして使用できます。
一つのメタページがインデックスの最初のセグメントファイルの固定位置に格納されます。
それ以外の全てのページはリーフページか内部ページのいずれかです。
リーフページはツリーの最下階層にあるページです。
それ以外の全ての階層は内部ページで構成されます。
各リーフページはテーブルの行を指すタプルを含みます。
各内部ページはツリーの次の下位層を指すタプルを含みます。
典型的には、全ページの99％以上がリーフページです。
内部ページとリーフページは共に、<a class="xref" href="storage-page-layout.html" title="66.6. データベースページのレイアウト">66.6</a>に記載されている標準のページ書式を使用します。
</p><p>
<span class="original">
New leaf pages are added to a B-Tree index when an existing leaf
page cannot fit an incoming tuple. A <firstterm>page
split</firstterm> operation makes room for items that originally
belonged on the overflowing page by moving a portion of the items
to a new page. Page splits must also insert a new
<firstterm>downlink</firstterm> to the new page in the parent page,
which may cause the parent to split in turn. Page splits
<quote>cascade upwards</quote> in a recursive fashion. When the
root page finally cannot fit a new downlink, a <firstterm>root page
split</firstterm> operation takes place. This adds a new level to
the tree structure by creating a new root page that is one level
above the original root page.
</span>
既存リーフページがやってくるタプルをはめ込むことができないとき、新たなリーフページがB-Treeインデックスに追加されます。
<em class="firstterm">ページ分割</em>操作は一部のアイテムを新ページに動かすことで、当初は溢れているページに属していたアイテムのために空間を作ります。
ページ分割は、また、新ページへの新たな<em class="firstterm">ダウンリンク</em>を親ページに挿入しなければなりません。これは親ページの分割を同様に引き起こすかもしれません。
ページは分割は再帰的に<span class="quote">「<span class="quote">上向きに連鎖</span>」</span>します。
最終的にルートページが新たなダウンリンクをはめ込みできないときには、<em class="firstterm">ルートページ分割</em>が実施されます。
これは元のルートページの一つ上の階層に新たなルートページを作ることで、ツリー構造に新しい階層を加えます。
</p></div><div class="sect3" id="BTREE-DELETION"><div class="titlepage"><div><div><h4 class="title">65.1.4.2. ボトムアップインデックスの削除 <a href="#BTREE-DELETION" class="id_link">#</a></h4></div></div></div><span class="original">
<title>Bottom-up Index Deletion</title>
</span><p>
<span class="original">
B-Tree indexes are not directly aware that under MVCC, there might
be multiple extant versions of the same logical table row; to an
index, each tuple is an independent object that needs its own index
entry. <quote>Version churn</quote> tuples may sometimes
accumulate and adversely affect query latency and throughput. This
typically occurs with <command>UPDATE</command>-heavy workloads
where most individual updates cannot apply the
<link linkend="storage-hot"><acronym>HOT</acronym> optimization.</link>
Changing the value of only
one column covered by one index during an <command>UPDATE</command>
<emphasis>always</emphasis> necessitates a new set of index tuples
&mdash; one for <emphasis>each and every</emphasis> index on the
table. Note in particular that this includes indexes that were not
<quote>logically modified</quote> by the <command>UPDATE</command>.
All indexes will need a successor physical index tuple that points
to the latest version in the table. Each new tuple within each
index will generally need to coexist with the original
<quote>updated</quote> tuple for a short period of time (typically
until shortly after the <command>UPDATE</command> transaction
commits).
</span>
B-Treeインデックスは、MVCCの下で同じ論理テーブル行の複数の現存するバージョンが存在する可能性があることを直接認識していません。
インデックスに対して、各タプルは独自のインデックスエントリを必要とする独立したオブジェクトです。
<span class="quote">「<span class="quote">バージョンチャーン</span>」</span>タプルは蓄積し、クエリ待ち時間とスループットに悪影響を与える可能性があります。
これは通常、個々の更新のほとんどが<a class="link" href="storage-hot.html" title="66.7. ヒープ専用タプル(HOT)"><acronym class="acronym">HOT</acronym>最適化</a>を適用できないような<code class="command">UPDATE</code>の重いワークロードで発生します。
<code class="command">UPDATE</code>中にあるインデックスによって、カバーされる一つだけの行の値を変更するには、新しいインデックスタプルのセットを<span class="emphasis"><em>いつも</em></span>必要とします。
テーブル上にある <span class="emphasis"><em>ありとあらゆる</em></span>インデックスにつき一つです。
具体的には、<code class="command">UPDATE</code>によって<span class="quote">「<span class="quote">論理的に変更</span>」</span>されなかったインデックスが含まれることに注意してください。
すべてのインデックスは、テーブル上で最新バージョンを指す後継の物理的なインデックスタプルを必要とします。
各インデックス中のそれぞれの新しいタプルは通常元の<span class="quote">「<span class="quote">更新された</span>」</span>タプルと短期間共存する必要があります（通常、<code class="command">UPDATE</code>トランザクションのコミットした直後までです）。
</p><p>
<span class="original">
B-Tree indexes incrementally delete version churn index tuples by
performing <firstterm>bottom-up index deletion</firstterm> passes.
Each deletion pass is triggered in reaction to an anticipated
<quote>version churn page split</quote>. This only happens with
indexes that are not logically modified by
<command>UPDATE</command> statements, where concentrated build up
of obsolete versions in particular pages would occur otherwise. A
page split will usually be avoided, though it's possible that
certain implementation-level heuristics will fail to identify and
delete even one garbage index tuple (in which case a page split or
deduplication pass resolves the issue of an incoming new tuple not
fitting on a leaf page). The worst-case number of versions that
any index scan must traverse (for any single logical row) is an
important contributor to overall system responsiveness and
throughput. A bottom-up index deletion pass targets suspected
garbage tuples in a single leaf page based on
<emphasis>qualitative</emphasis> distinctions involving logical
rows and versions. This contrasts with the <quote>top-down</quote>
index cleanup performed by autovacuum workers, which is triggered
when certain <emphasis>quantitative</emphasis> table-level
thresholds are exceeded (see <xref linkend="autovacuum"/>).
</span>
B-Treeインデックスは、<em class="firstterm">ボトムアップインデックスの削除</em>パスの実行によって、バージョンチャーンのインデックスタプルを徐々に削除します。
各削除パスは、予期された<span class="quote">「<span class="quote">バージョンチャーンのページ分割</span>」</span>に対してトリガされます。
これは、<code class="command">UPDATE</code>文によって論理的に変更されてないインデックスだけで発生します。
さもないと、特定のページで使われなくなったバージョンが集中的に蓄積されます。
ある種の実装レベルの発見的手法は、均一のごみインデックスタプルの特定及び削除に失敗する可能がありますが、ページの分割は通常避けることができます（ページ分割もしくは重複排除パスの場合に、リーフページ上の収まらない新しいタプルが入ることの問題が解決します）。
インデックススキャンが（単一の論理行に対して）通過しなければならない最悪の場合のバージョン数は、システム全体の応答性やスループットに重要な影響があります。
ボトムアップインデックス削除パスは、論理行とバージョンを含む<span class="emphasis"><em>定性的な</em></span>特徴に基づいた単一のリーフページ内の疑わしいごみタプルを対象としています。
これは、一定の<span class="emphasis"><em>定量的な</em></span>テーブルレベルの閾値が超えられたとき（<a class="xref" href="routine-vacuuming.html#AUTOVACUUM" title="24.1.6. 自動バキュームデーモン">24.1.6</a>参照）に起動されるautovacuumワーカーによって実行された<span class="quote">「<span class="quote">トップダウン</span>」</span>インデックスのクリーンアップと対照的です。
</p><div class="note"><h3 class="title">注記</h3><p>
<span class="original">
Not all deletion operations that are performed within B-Tree
indexes are bottom-up deletion operations. There is a distinct
category of index tuple deletion: <firstterm>simple index tuple
deletion</firstterm>. This is a deferred maintenance operation
that deletes index tuples that are known to be safe to delete
(those whose item identifier's <literal>LP_DEAD</literal> bit is
already set). Like bottom-up index deletion, simple index
deletion takes place at the point that a page split is anticipated
as a way of avoiding the split.
</span>
B-Treeインデックス内で実行されたすべての削除操作がボトムアップ削除操作とは限りません。
インデックスタプルの削除の異なる分類があります。
それは、<em class="firstterm">単純なインデックスのタプル削除</em>です。
これは、削除が安全であると分かるインデックスタプル(アイテム識別子の<code class="literal">LP_DEAD</code>ビットが既に設定されているタプル)を削除する遅延メンテナンス操作です。
ボトムアップインデックス削除と同様に、単純インデックス削除は分割を回避する方法としてページ分割が予測された時点で実行されます。
</p><p>
<span class="original">
Simple deletion is opportunistic in the sense that it can only
take place when recent index scans set the
<literal>LP_DEAD</literal> bits of affected items in passing.
Prior to <productname>PostgreSQL</productname> 14, the only
category of B-Tree deletion was simple deletion. The main
differences between it and bottom-up deletion are that only the
former is opportunistically driven by the activity of passing
index scans, while only the latter specifically targets version
churn from <command>UPDATE</command>s that do not logically modify
indexed columns.
</span>
単純削除は、最近のインデックススキャンでは影響があるアイテムに<code class="literal">LP_DEAD</code>ビットをセットする際に、ついでに実行できる機会の場合のみに実行されるという意味で、機会主義と言えます。
<span class="productname">PostgreSQL</span> 14より前では、B-Treeの削除の種類は単純な削除のみでした。
単純な削除とボトムアップ削除の主な違いは、前者だけがインデックススキャンの動きによって機会を狙って駆動されることに対して、後者だけがインデックスカラムが論理的に変更されない<code class="command">UPDATE</code>からのバージョンチャーンを具体的に対象とすることです。
</p></div><p>
<span class="original">
Bottom-up index deletion performs the vast majority of all garbage
index tuple cleanup for particular indexes with certain workloads.
This is expected with any B-Tree index that is subject to
significant version churn from <command>UPDATE</command>s that
rarely or never logically modify the columns that the index covers.
The average and worst-case number of versions per logical row can
be kept low purely through targeted incremental deletion passes.
It's quite possible that the on-disk size of certain indexes will
never increase by even one single page/block despite
<emphasis>constant</emphasis> version churn from
<command>UPDATE</command>s. Even then, an exhaustive <quote>clean
sweep</quote> by a <command>VACUUM</command> operation (typically
run in an autovacuum worker process) will eventually be required as
a part of <emphasis>collective</emphasis> cleanup of the table and
each of its indexes.
</span>
ボトムアップインデックス削除は、明確なワークロードによる特定インデックスのすべてのゴミインデックスタプルの掃除の大多数を実行します。
これは、インデックスがカバーするカラムを論理的に変更することが滅多にまたは決してない<code class="command">UPDATE</code>からの有意なバージョンチャーンに依存するB-Treeインデックスで予想されます。
論理行ごとのバージョン数の平均と最も悪いケースは、対象とされた増分削除パスによって純粋に低く維持することができます。
特定インデックスのディスク上のサイズは、<code class="command">UPDATE</code>からの<span class="emphasis"><em>一定の</em></span>バージョンチャーンがあるにも関わらず、ページやブロックが一つも増加することがない可能性が十分にあります。
そのような場合でも、<code class="command">VACUUM</code>操作（通常、自動バキュームワーカープロセスで実行します）による、徹底的な<span class="quote">「<span class="quote">一掃</span>」</span>が、テーブルとその各インデックスの<span class="emphasis"><em>共通の</em></span>クリーンアップの一部として最終的に要求されます。
</p><p>
<span class="original">
Unlike <command>VACUUM</command>, bottom-up index deletion does not
provide any strong guarantees about how old the oldest garbage
index tuple may be. No index can be permitted to retain
<quote>floating garbage</quote> index tuples that became dead prior
to a conservative cutoff point shared by the table and all of its
indexes collectively. This fundamental table-level invariant makes
it safe to recycle table <acronym>TID</acronym>s. This is how it
is possible for distinct logical rows to reuse the same table
<acronym>TID</acronym> over time (though this can never happen with
two logical rows whose lifetimes span the same
<command>VACUUM</command> cycle).
</span>
<code class="command">VACUUM</code>とは異なり、ボトムアップインデックス削除は最も古いゴミのインデックスタプルがどのくらい経過しているかについて強い保証を提供しません。
テーブルと全てのインデックスの合計によって共通する保守的な切り捨て点より前に、不要になる<span class="quote">「<span class="quote">浮いているゴミ</span>」</span>インデックスタプルの維持を許可することはできません。
この基本的なテーブルレベルの不変条件は、テーブルの<acronym class="acronym">TID</acronym>を安全にリサイクルします。
これにより、時間の経過と共に異なる論理行が同じテーブル<acronym class="acronym">TID</acronym>を再利用することが可能です（ただし、これは存続期間が同じ<code class="command">VACUUM</code>サイクルにまたがる、二つの論理行に同時には発生しません）。
</p></div><div class="sect3" id="BTREE-DEDUPLICATION"><div class="titlepage"><div><div><h4 class="title">65.1.4.3. 重複排除 <a href="#BTREE-DEDUPLICATION" class="id_link">#</a></h4></div></div></div><span class="original">
<title>Deduplication</title>
</span><p>
<span class="original">
A duplicate is a leaf page tuple (a tuple that points to a table
row) where <emphasis>all</emphasis> indexed key columns have values
that match corresponding column values from at least one other leaf
page tuple in the same index. Duplicate tuples are quite common in
practice. B-Tree indexes can use a special, space-efficient
representation for duplicates when an optional technique is
enabled: <firstterm>deduplication</firstterm>.
</span>
重複とは、同じインデックスで<span class="emphasis"><em>全ての</em></span>インデックスキー列が少なくとも一つの他のリーフページタプルの該当する列の値と一致する値をもっている、リーフページタプル（テーブルの行を指すタプル）です。
重複タプルは実際によくあります。
オプションの技法「<em class="firstterm">重複排除</em>」が有効にされているとき、B-Treeインデックスは、特別な重複に対する空間効率の良い表現方法を使用できます。
</p><p>
<span class="original">
Deduplication works by periodically merging groups of duplicate
tuples together, forming a single <firstterm>posting list</firstterm> tuple for each
group. The column key value(s) only appear once in this
representation. This is followed by a sorted array of
<acronym>TID</acronym>s that point to rows in the table. This
significantly reduces the storage size of indexes where each value
(or each distinct combination of column values) appears several
times on average. The latency of queries can be reduced
significantly. Overall query throughput may increase
significantly. The overhead of routine index vacuuming may also be
reduced significantly.
</span>
重複排除は重複タプルのグループを定期的に合併して、各グループに対する単一の<em class="firstterm">ポスティングリスト</em>タプルを形成することで機能します。
この表現方法では列のキー値は一度だけ現れます。
テーブルの行を指す<acronym class="acronym">TID</acronym>のソートされた配列がこれに続きます。
概して各値（あるいは列値の異なる組み合わせ）が複数回出現する場合に、これは顕著にインデックスの格納サイズを減らします。
問い合わせの遅延も顕著に削減できます。
全体的な問い合わせのスループットも顕著に増加するかもしれません。
インデックスのバキューム処理のオーバーヘッドも顕著に削減されるかもしれません。
</p><div class="note"><h3 class="title">注記</h3><p>
<span class="original">
B-Tree deduplication is just as effective with
<quote>duplicates</quote> that contain a NULL value, even though
NULL values are never equal to each other according to the
<literal>=</literal> member of any B-Tree operator class. As far
as any part of the implementation that understands the on-disk
B-Tree structure is concerned, NULL is just another value from the
domain of indexed values.
</span>
B-Tree重複排除は、B-Tree演算子クラスの<code class="literal">=</code>項に従ってNULL値が決して互いに等しくならないとしても、NULL値を含む<span class="quote">「<span class="quote">重複</span>」</span>に対しても同様に効果的です。
ディスク上のB-Tree構造を理解するいかなる実装部分に関しても、NULLはインデックス値の定義域からの他の値に過ぎません。
</p></div><p>
<span class="original">
The deduplication process occurs lazily, when a new item is
inserted that cannot fit on an existing leaf page, though only when
index tuple deletion could not free sufficient space for the new
item (typically deletion is briefly considered and then skipped
over). Unlike GIN posting list tuples, B-Tree posting list tuples
do not need to expand every time a new duplicate is inserted; they
are merely an alternative physical representation of the original
logical contents of the leaf page. This design prioritizes
consistent performance with mixed read-write workloads. Most
client applications will at least see a moderate performance
benefit from using deduplication. Deduplication is enabled by
default.
</span>
既存のリーフページに収まらない新たな要素が挿入されたとき、重複排除の処理は怠惰に実行されますが、インデックスタプルの削除は新しいアイテムのための十分なスペースを解放できなかった場合に限ります（通常、削除は簡易に検討した上で無視されます）。
GINのポスティングリストのタプルと違って、B-Treeのポスティングリストのタプルは新たな重複が挿入される度に拡張する必要がありません。それらはリーフページの元の論理内容に対する単なる代替の物理表現にすぎません。
この設計は読み書き混合のワークロードでの性能の一貫性を重視しています。
ほとんどのクライアントアプリケーションは重複排除を使うことで少なくとも控えめな性能の恩恵を確認することができるでしょう。
重複排除はデフォルトで有効になっています。
</p><p>
<span class="original">
<command>CREATE INDEX</command> and <command>REINDEX</command>
apply deduplication to create posting list tuples, though the
strategy they use is slightly different. Each group of duplicate
ordinary tuples encountered in the sorted input taken from the
table is merged into a posting list tuple
<emphasis>before</emphasis> being added to the current pending leaf
page. Individual posting list tuples are packed with as many
<acronym>TID</acronym>s as possible. Leaf pages are written out in
the usual way, without any separate deduplication pass. This
strategy is well-suited to <command>CREATE INDEX</command> and
<command>REINDEX</command> because they are once-off batch
operations.
</span>
<code class="command">CREATE INDEX</code>と<code class="command">REINDEX</code>は、使用する手順が若干異なりますが、ポスティングリストタプルを作って重複排除を適用します。
テーブルから取得されてソートされた入力で遭遇した重複した通常タプルの各グループは、現在のペンディングリーフページに追加される<span class="emphasis"><em>前に</em></span>、ポスティングリストタプルにマージされます。
個別のポスティングリストタプルには、可能な限り多数の<acronym class="acronym">TID</acronym>が詰め込まれます。
リーフページは、重複排除用の別パスではなく、通常の方法で書き出されます。
この戦略は<code class="command">CREATE INDEX</code>と<code class="command">REINDEX</code>に良く適合します。これらは1回で終わるバッチ操作であるからです。
</p><p>
<span class="original">
Write-heavy workloads that don't benefit from deduplication due to
having few or no duplicate values in indexes will incur a small,
fixed performance penalty (unless deduplication is explicitly
disabled). The <literal>deduplicate_items</literal> storage
parameter can be used to disable deduplication within individual
indexes. There is never any performance penalty with read-only
workloads, since reading posting list tuples is at least as
efficient as reading the standard tuple representation. Disabling