pgsql-server/src/backend/utils/sort tuplesort.c

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