Re: GiST indexes and concurrency (tsearch2)
От | Marinos Yannikos |
---|---|
Тема | Re: GiST indexes and concurrency (tsearch2) |
Дата | |
Msg-id | 4204C3B4.1050209@geizhals.at обсуждение исходный текст |
Ответ на | Re: GiST indexes and concurrency (tsearch2) (Oleg Bartunov <oleg@sai.msu.su>) |
Ответы |
Re: GiST indexes and concurrency (tsearch2)
Re: GiST indexes and concurrency (tsearch2) |
Список | pgsql-performance |
Oleg Bartunov schrieb: > Marinos, > > 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. Regards, Marinos
В списке pgsql-performance по дате отправления: