Oleg Bartunov schrieb:

what if you construct "apachebench & Co" free  script and see if
the issue still exists. There are could be many issues doesn't
connected to postgresql and tsearch2.

Some more things I tried:
- data directory on ramdisk (tmpfs) - no effect
- database connections either over Unix domain sockets or TCP - no effect
- CLUSTER on gist index - approx. 20% faster queries, but CPU usage still hovers around 25% (75% idle)
- preemptible kernel - no effect

This is really baffling me, it looks like a kernel issue of some sort (I'm only guessing though). I found this old posting: http://archives.postgresql.org/pgsql-general/2001-12/msg00836.php - is this still applicable? I don't see an unusually high number of context switches, but the processes seem to be spending some time in "semtimedop" (even though the TAS assembly macros are definetely being compiled-in).

If you are interested, I can probably provide an account on one of our identically configured boxes by Monday afternoon (GMT+1) with the same database and benchmarking utility.


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
     joining column's datatypes do not match

Reply via email to