Re: [GENERAL] Creation of tsearch2 index is very slow

Well, I feel like a fool, because I failed to notice that the total
runtime shown in that profile wasn't anywhere close to the actual wall
clock time.  gprof is indeed simply not counting the time spent in
dynamically-linked code.  With tsearch2 statically linked into the
backend, a more believable picture emerges:

  %   cumulative   self              self     total
 time   seconds   seconds    calls  Ks/call  Ks/call  name
 98.96   1495.93  1495.93 33035195     0.00     0.00  hemdistsign
  0.27   1500.01     4.08 10030581     0.00     0.00  makesign
  0.11   1501.74     1.73   588976     0.00     0.00  gistchoose
  0.10   1503.32     1.58   683471     0.00     0.00  XLogInsert
  0.05   1504.15     0.83   246579     0.00     0.00  sizebitvec
  0.05   1504.93     0.78   446399     0.00     0.00  gtsvector_union
  0.03   1505.45     0.52  3576475     0.00     0.00  LWLockRelease
  0.03   1505.92     0.47     1649     0.00     0.00  gtsvector_picksplit
  0.03   1506.38     0.47  3572572     0.00     0.00  LWLockAcquire
  0.02   1506.74     0.36   444817     0.00     0.00  gtsvector_same
  0.02   1507.09     0.35  4077089     0.00     0.00  AllocSetAlloc
  0.02   1507.37     0.28   236984     0.00     0.00  gistdoinsert
  0.02   1507.63     0.26   874195     0.00     0.00  hash_search
  0.02   1507.89     0.26  9762101     0.00     0.00  gtsvector_penalty
  0.01   1508.08     0.19   236984     0.00     0.00  gistmakedeal
  0.01   1508.27     0.19   841754     0.00     0.00  UnpinBuffer
  0.01   1508.45     0.18 22985469     0.00     0.00  hemdistcache
  0.01   1508.63     0.18  3998572     0.00     0.00  LockBuffer
  0.01   1508.81     0.18   686681     0.00     0.00  gtsvector_compress
  0.01   1508.98     0.17 11514275     0.00     0.00  gistdentryinit

So we gotta fix hemdistsign ...

            regards, tom lane