Re: GiST indexes and concurrency (tsearch2)

Marinos Yannikos <mjy(at)geizhals(dot)at> writes:
> 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?

That seems to be an early report of what we now recognize as the
"context swap storm" problem, and no we don't have a solution yet.
I'm not completely convinced that you're seeing the same thing,
but if you're seeing a whole lot of semops then it could well be.

I set up a test case consisting of two backends running the same
tsearch2 query over and over --- nothing fancy, just one of the ones
from the tsearch2 regression test:
SELECT count(*) FROM test_tsvector WHERE a @@ to_tsquery('345&qwerty');
I used gdb to set breakpoints at PGSemaphoreLock and PGSemaphoreTryLock,
which are the only two functions that can possibly block on a semop
call. On a single-processor machine, I saw maybe one hit every couple
of seconds, all coming from contention for the BufMgrLock or sometimes
the LockMgrLock. So unless I've missed something, there's not anything
in tsearch2 or gist per se that is causing lock conflicts. You said
you're testing a quad-processor machine, so it could be that you're
seeing the same lock contention issues that we've been trying to figure
out for the past year ...

regards, tom lane