pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Martijn van Oosterhout <kleptog@svana.org>
Cc: Stephan Vollmer <svollmer@gmx.de>
Cc: pgsql-performance@postgreSQL.org
Subject: Re: [GENERAL] Creation of tsearch2 index is very slow
Date: Fri, 20 Jan 2006 16:19:15 -0500
Message-ID: <26958.1137791955@sss.pgh.pa.us> (raw)
In-Reply-To: <20060120205132.GF31908@svana.org>
References: <43D0ED57.1020608@gmx.de>
	<17454.1137771321@sss.pgh.pa.us>
	<20060120170452.GC31908@svana.org>
	<26153.1137784469@sss.pgh.pa.us>
	<20060120201036.GE31908@svana.org>
	<26583.1137788505@sss.pgh.pa.us>
	<20060120205132.GF31908@svana.org>

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



view thread (38+ messages)  latest in thread

Message-ID: <26958.1137791955@sss.pgh.pa.us>
Permalink:  ../26958.1137791955@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/26958.1137791955@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, kleptog@svana.org, svollmer@gmx.de
  Subject: Re: [GENERAL] Creation of tsearch2 index is very slow
  In-Reply-To: <26958.1137791955@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox