Thread: pgsql-server/src/backend/utils/sort tuplesort.c
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: tgl@svr1.postgresql.org 04/03/17 18:24:58
Modified files:
src/backend/utils/sort: tuplesort.c
Log message:
During btree index build, sort equal-keyed tuples according to their
TID (heap position). This doesn't do anything to the validity of the
finished index, but by pretending to qsort() that there are no really
equal keys in the sort, we can avoid performance problems with qsort
implementations that have trouble with large numbers of equal keys.
Patch from Manfred Koizar.
Tom Lane wrote: > CVSROOT: /cvsroot > Module name: pgsql-server > Changes by: tgl@svr1.postgresql.org 04/03/17 18:24:58 > > Modified files: > src/backend/utils/sort: tuplesort.c > > Log message: > During btree index build, sort equal-keyed tuples according to their > TID (heap position). This doesn't do anything to the validity of the > finished index, but by pretending to qsort() that there are no really > equal keys in the sort, we can avoid performance problems with qsort > implementations that have trouble with large numbers of equal keys. > Patch from Manfred Koizar. I think there is also the advantage that many equal keys will access the heap in a more sequential, rather than random, order, which is the part that really excited me. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> During btree index build, sort equal-keyed tuples according to their
>> TID (heap position). This doesn't do anything to the validity of the
>> finished index, but by pretending to qsort() that there are no really
>> equal keys in the sort, we can avoid performance problems with qsort
>> implementations that have trouble with large numbers of equal keys.
>> Patch from Manfred Koizar.
> I think there is also the advantage that many equal keys will access the
> heap in a more sequential, rather than random, order, which is the part
> that really excited me.
But we aren't attempting to maintain that ordering after index build.
(In fact, it was exactly that point that triggered the argument last
time round ...)
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> During btree index build, sort equal-keyed tuples according to their > >> TID (heap position). This doesn't do anything to the validity of the > >> finished index, but by pretending to qsort() that there are no really > >> equal keys in the sort, we can avoid performance problems with qsort > >> implementations that have trouble with large numbers of equal keys. > >> Patch from Manfred Koizar. > > > I think there is also the advantage that many equal keys will access the > > heap in a more sequential, rather than random, order, which is the part > > that really excited me. > > But we aren't attempting to maintain that ordering after index build. > (In fact, it was exactly that point that triggered the argument last > time round ...) Agreed, but we don't maintain CLUSTER either. I see no harm in having it start out ordered, at least. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073