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
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
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 e
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 index search. I'm not hugely
hopeful that this will he
Marinos Yannikos <[EMAIL PROTECTED]> 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 earl
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 eith
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:0
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 cha
"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
>
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,
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:
conc
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?
http://arc
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 detail
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 impossibl
It seems to be a big problem with tsearch2, when multiple clients are
hammering the db (we have a quad opteron box here that stays 75% idle
despite an apachebench with concurrency 10 stressing the php script that
uses tsearch2, with practically no disk accesses)
Concurrency with READs is fine -
"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
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
17 matches
Mail list logo
