Tom Lane wrote:
You might try the attached patch (which I just applied to HEAD).
It cuts down the number of acquisitions of the BufMgrLock by merging
adjacent bufmgr calls during a GIST index search. [...]
Thanks - I applied it successfully against 8.0.0, but it didn't seem to
have a noticeable
Tom Lane wrote:
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'm seeing ~280 semops/second with spinlocks enabled and ~80k
semops/second ( 4 mil. for 100 queries) with --disable-spinlocks, which
increases total
On Sat, 2005-02-05 at 14:42 -0500, Tom Lane wrote:
Marinos Yannikos [EMAIL PROTECTED] writes:
Some more things I tried:
You might try the attached patch (which I just applied to HEAD).
It cuts down the number of acquisitions of the BufMgrLock by merging
adjacent bufmgr calls during a GIST
On Thu, 3 Feb 2005, Marinos J. Yannikos wrote:
Hi,
according to http://www.postgresql.org/docs/8.0/interactive/limitations.html
, concurrent access to GiST indexes isn't possible at the moment. I haven't
read the thesis mentioned there, but I presume that concurrent read access is
also
Oleg Bartunov wrote:
On Thu, 3 Feb 2005, Marinos J. Yannikos wrote:
concurrent access to GiST indexes isn't possible at the moment. I [...]
there are should no problem with READ access.
OK, thanks everyone (perhaps it would make sense to clarify this in the
manual).
I'm willing to see some
Do you have anything performing any updates or inserts to this table,
even if it does not update the gist column, even if it does not update
anything ?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
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.
Oleg
On Thu, 3 Feb 2005, Marinos J. Yannikos wrote:
Oleg Bartunov wrote:
On Thu, 3 Feb 2005, Marinos J. Yannikos wrote:
Oleg Bartunov wrote:
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.
Yes, the problem persists - I wrote a small perl script that forks 10
chils processes and executes the
Marinos J. Yannikos [EMAIL PROTECTED] writes:
I can't seem to find out where the bottleneck is, but it doesn't seem to
be CPU or disk. top shows that postgres processes are frequently in
this state:
6701 postgres 16 0 204m 58m 56m S 9.3 0.2 0:06.96 semtimedo
Tom Lane schrieb:
What's the platform exactly (hardware and OS)?
Hardware: http://www.appro.com/product/server_1142h.asp
- SCSI version, 2 x 146GB 10k rpm disks in software RAID-1
- 32GB RAM
OS: Linux 2.6.10-rc3, x86_64, debian GNU/Linux distribution
- CONFIG_K8_NUMA is currently turned off (no
On Thu, 3 Feb 2005, Tom Lane wrote:
Marinos J. Yannikos [EMAIL PROTECTED] writes:
I can't seem to find out where the bottleneck is, but it doesn't seem to
be CPU or disk. top shows that postgres processes are frequently in
this state:
6701 postgres 16 0 204m 58m 56m S 9.3 0.2 0:06.96
Hi,
according to
http://www.postgresql.org/docs/8.0/interactive/limitations.html ,
concurrent access to GiST indexes isn't possible at the moment. I
haven't read the thesis mentioned there, but I presume that concurrent
read access is also impossible. Is there any workaround for this, esp.
if
Marinos J. Yannikos [EMAIL PROTECTED] writes:
according to
http://www.postgresql.org/docs/8.0/interactive/limitations.html ,
concurrent access to GiST indexes isn't possible at the moment. I
haven't read the thesis mentioned there, but I presume that concurrent
read access is also
13 matches
Mail list logo
