On Mon, 2004-10-25 at 17:17, Curt Sampson wrote:
When you select all the columns, you're going to force it to go to the
table. If you select only the indexed column, it ought to be able to use
just the index, and never read the table at all.
Perhaps in other database systems, but not in
Curt Sampson wrote:
On Sun, 24 Oct 2004, John Meinel wrote:
I was looking into another problem, and I found something that surprised
me. If I'm doing SELECT * FROM mytable WHERE col = 'myval' LIMIT 1..
Now col is indexed...
The real purpose of this query is to check to see if a value exists in
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
Has anyone tried to replace the whole lwlock implementation with
pthread_rwlock? At least for Linux with recent glibcs, pthread_rwlock is
implemented with futexes, i.e. we would get a fast lock handling without
os specific hacks.
Mark Wong wrote:
Here are some other details, per Manfred's request:
Linux 2.6.8.1 (on a gentoo distro)
How complicated are Tom's test scripts? His immediate reply was that I
should retest with Fedora, to rule out any gentoo bugs.
I have a dual-cpu system with RH FC, I could use it for
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
Tom Lane wrote:
The bigger problem here is that the SMP locking bottlenecks we are
currently seeing are *hardware* issues (AFAICT anyway). The only way
that futexes can offer a performance win is if they have a smarter way
of
Mark Wong wrote:
Pretty, simple. One to load the database, and 1 to query it. I'll
attach them.
I've tested it on my dual-cpu computer:
- it works, both cpus run within the postmaster. It seems something your
gentoo setup is broken.
- the number of context switch is down slightly, but not
Thomas F.O'Connell wrote:
I'm seeing some weird behavior on a repurposed server that was wiped
clean and set up to run as a database and application server with
postgres and Apache, as well as some command-line PHP scripts.
The box itself is a quad processor (2.4 GHz Intel Xeons) Debian woody
I haven't read much FAQs but has anyone done some benchmarks with
different io schedulers in linux with postgresql?
Look at these:
http://kerneltrap.org/node/view/843
http://simonraven.nuit.ca/blog/archives/2004/05/20/quikconf/
Maybe its well known knowledge but i just found this information
I wrote:
I don't have the URL at hand but it was posted just a few days ago.
... actually, it was the beginning of this here thread ...
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once
Mark Wong wrote:
I've heard that simply linking to the pthreads libraries, regardless of
whether you're using them or not creates a significant overhead. Has
anyone tried it for kicks?
That depends on the OS and the functions that are used. The typical
worst case is buffered IO of single
Manfred,
How complicated are Tom's test scripts? His immediate reply was that I
should retest with Fedora, to rule out any gentoo bugs.
We've done some testing on other Linux.Linking in pthreads reduced CSes by
15%, which was no appreciable impact on real performance.
Gavin/Neil's full
Manfred Spraul [EMAIL PROTECTED] writes:
But: According to the descriptions the problem is a context switch
storm. I don't see that cache line bouncing can cause a context switch
storm. What causes the context switch storm?
As best I can tell, the CS storm arises because the backends get
Bjorn,
I haven't read much FAQs but has anyone done some benchmarks with
different io schedulers in linux with postgresql?
According to OSDL, using the deadline scheduler sometimes results in a
roughly 5% boost to performance, and sometimes none, depending on the
application. We use it for
Manfred Spraul [EMAIL PROTECTED] writes:
Tom Lane wrote:
It could be that I'm all wet and there is no relationship between the
cache line thrashing and the seemingly excessive BufMgrLock contention.
Is it important? The fix is identical in both cases: per-bucket locks
for the hash table
Hi,
I am dealing with an app here that uses pg to handle a few
thousand concurrent web users. It seems that under heavy load, the INSERT and
UPDATE statements to one or two specific tables keep queuing up, to the count
of 150+ (one table has about 432K rows, other has about 2.6Million
On Mon, 2004-10-25 at 16:53, Anjan Dave wrote:
Hi,
I am dealing with an app here that uses pg to handle a few thousand
concurrent web users. It seems that under heavy load, the INSERT and
UPDATE statements to one or two specific tables keep queuing up, to
the count of 150+ (one table
On Oct 25, 2004, at 13:53, Anjan Dave wrote:
I am dealing with an app here that uses pg to handle a few thousand
concurrent web users. It seems that under heavy load, the INSERT and
UPDATE statements to one or two specific tables keep queuing up, to
the count of 150+ (one table has about 432K
17 matches
Mail list logo
